[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <559CFF18.8090803@arm.com>
Date: Wed, 08 Jul 2015 11:44:40 +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>
Subject: Re: [PATCH 3/4] irqchip, gicv3: Implement Cavium ThunderX erratum
23154
On 08/07/15 11:28, Robert Richter wrote:
> Marc,
>
> On 06.07.15 11:43:02, Marc Zyngier wrote:
>> On 30/06/15 15:14, Robert Richter wrote:
>>> static const struct gic_capabilities gicv3_errata[] = {
>>> {
>>> + .desc = "GIC: Cavium erratum 23154",
>>> + .id = 0xa100034c, /* ThunderX pass 1.x */
>>> + .mask = 0xffff0fff,
>>> + .init = gicv3_enable_cavium_thunderx,
>>> + },
>>> + {
>>> }
>>> };
>>>
>>>
>>
>> How does this work when running a guest? Does the virtualized access
>> suffer from the same erratum? If that's the case, we need a better
>> workaround...
>
> We need to apply the workaround also for guests. So you are right,
> evaluating GICD_IIDR does not enable the workaround then as the
> register is emulated with ARM as implementer.
>
> We considering MIDR_EL1 as a version check for this errata now. This
> should be the host's cpuid when running as a guest, right?
Yes, that should work, as we don't repaint MIDR_EL1 *yet*. But it also
means that we're going to have a hard time emulating another CPU (such
as A57) on top of ThunderX. Probably not a big deal at the moment...
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/
Powered by blists - more mailing lists