linux-kernel - Re: [PATCH v2 3/5] irqchip, gicv3: Workaround for Cavium ThunderX erratum 23154

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 13 Aug 2015 17:54:41 +0100
From:	Marc Zyngier <marc.zyngier@....com>
To:	Robert Richter <robert.richter@...iumnetworks.com>
CC:	Robert Richter <rric@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jason Cooper <jason@...edaemon.net>,
	Tirumalesh Chalamarla <tchalamarla@...ium.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Will Deacon <will.deacon@....com>
Subject: Re: [PATCH v2 3/5] irqchip, gicv3: Workaround for Cavium ThunderX
 erratum 23154

On 13/08/15 17:17, Robert Richter wrote:
> Marc,
> 
> thanks for your quick review.
> 
> On 13.08.15 16:11:15, Marc Zyngier wrote:
>> On 13/08/15 15:47, Robert Richter wrote:
>>> From: Robert Richter <rrichter@...ium.com>
> 
>>>  static const struct gic_capabilities gicv3_errata[] = {
>>>  	{
>>> +		.desc		= "GIC: Cavium erratum 23154",
>>> +		.iidr		= 0xa100034c,	/* ThunderX pass 1.x */
>>> +		.iidr_mask	= 0xffff0fff,
>>> +		.init		= gicv3_enable_cavium_thunderx,
>>> +	},
>>
>> I'm even more puzzled. You're working around a CPU bug based on the ITS
>> ID registers? Or have you swapped the detection methods for the two errata?
> 
> :/ Right, I mixed this up... Must have starred on this for too long.
> Will fix that.
> 
> Wrt midr: Originally this was written to support iidr. I wanted to
> keep the version check in the driver of the hw, an implementation
> outside of drivers/irqchip looked not appropriate here as it would
> rely then on arch arm64 only. This is the main reason. Apart from
> that, I think an implmentation based on struct arm64_cpu_capabilities,
> etc. would require much rework compared to my current easy
> implementation, e.g:
> 
>  * binding flags to callbacks and actually run them,
> 
>  * handing over private driver data (base addr for iidr detection) to
>    a capabilty's match function.
> 
> Overall this looked bloated. Now, that the MIDR also needs to be
> checked, it looked better to me to keep the gic hw detection at a
> single location in the driver. This also allows us to check a
> combination of midr and iidr values.
> 
> I hope this sounds reasonable?

+Will.

The point I was trying to make is that a CPU interface bug is a CPU bug,
and that it feels quite weird weird to have the detection in the GIC.
Will, what do you think?

Also, I don't really buy the combined MIDR/GITS_IIDR detection. These
are two *very* distinct pieces of HW that are not even directly
connected (the redistributors are in between).

I wouldn't mind having something like:

struct gic_capabilities {
	const char *desc;
	void (*init)(void *data);
	u32 iidr;
	u32 iidr_mask;
	int feature;
};

where "feature" is a one of things declared in cpufeature.h, and that
would condition the capability (I love the name!) if that really
happens. I don't think we're there yet.

As for the complexity of implementation, testing a flag in the probe
function and tingling a static key is not really a big deal.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/