From: Marc Zyngier <maz@kernel.org>
To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, eric.auger@redhat.com,
Linuxarm <linuxarm@huawei.com>
Subject: Re: [PATCH] irqchip/gic-v3: Check SRE bit for GICv2 legacy support
Date: Mon, 30 Nov 2020 14:56:43 +0000 [thread overview]
Message-ID: <846387e4168f1a22638ad07ae670c531@kernel.org> (raw)
In-Reply-To: <85bb389a75f347d29ab3f75e4cfae060@huawei.com>
Hi Shameer,
On 2020-11-30 13:55, Shameerali Kolothum Thodi wrote:
> Hi Marc,
>
>> -----Original Message-----
>> From: Marc Zyngier [mailto:maz@kernel.org]
>> Sent: 30 November 2020 12:28
>> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
>> Cc: linux-kernel@vger.kernel.org;
>> linux-arm-kernel@lists.infradead.org;
>> eric.auger@redhat.com; Linuxarm <linuxarm@huawei.com>
>> Subject: Re: [PATCH] irqchip/gic-v3: Check SRE bit for GICv2 legacy
>> support
>>
>> Hi Shameer,
>>
>> On 2020-11-30 10:26, Shameer Kolothum wrote:
>> > At present, the support for GICv2 backward compatibility on GICv3/v4
>> > hardware is determined based on whether DT/ACPI provides a memory
>> > mapped phys base address for GIC virtual CPU interface register(GICV).
>> > This creates a problem that a Qemu guest boot with default GIC(GICv2)
>>
>> That'd be true of *any* guest using GICv2, not just when using QEMU as
>> the VMM, right?
>
> Yes, I would think so.
>
>> > hangs when firmware falsely reports this address on systems that don't
>> > have support for legacy mode.
>>
>> And I guess it isn't just the guest that hangs, but the whole system
>> can
>> go south (it would be totally legitimate for the HW to deliver a
>> SError).
>
> So far I haven’t seen that happening. I was able to kill the Guest and
> recover.
> But the annoying thing is Guest boot hangs at random places without any
> error reported and people end up spending lot of time only to be told
> later
> that gic-version=3 is missing from their scripts.
That's pretty lucky. The guest has been reading/writing to random
places,
and depending on where this maps in the physical space, anything can
happen. Out of (morbid) curiosity, what is at the address pointed to by
GICC in MADT?
>
>> > As per GICv3/v4 spec, in an implementation that does not support legacy
>> > operation, affinity routing and system register access are permanently
>> > enabled. This means that the associated control bits are RAO/WI. Hence
>> > use the ICC_SRE_EL1.SRE bit to decide whether hardware supports GICv2
>> > mode in addition to the above firmware based check.
>> >
>> > Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
>> > ---
>> > On Hisilicon D06, UEFI sets the GIC MADT GICC gicv_base_address but the
>> > GIC implementation on these boards doesn't have the GICv2 legacy
>> > support.
>> > This results in, Guest boot hang when Qemu uses the default GIC option.
>>
>> What a bore. Is this glorious firmware really out in the wild?
>
> :(. I am afraid it is.
Meh. We'll have to paper over it then. How urgent is that?
[...]
>> How about this instead? Completely untested, of course.
>
> Thanks for that. I just tested and it works.
OK. I'll rework it a bit and post it as a complete patch. Is there an
erratum number on your side?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2020-11-30 14:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-30 10:26 [PATCH] irqchip/gic-v3: Check SRE bit for GICv2 legacy support Shameer Kolothum
2020-11-30 11:50 ` Zenghui Yu
2020-11-30 12:06 ` Shameerali Kolothum Thodi
2020-11-30 13:16 ` Marc Zyngier
2020-11-30 12:28 ` Marc Zyngier
2020-11-30 13:55 ` Shameerali Kolothum Thodi
2020-11-30 14:56 ` Marc Zyngier [this message]
2020-11-30 16:20 ` Shameerali Kolothum Thodi
2020-11-30 18:31 ` Ard Biesheuvel
2020-12-02 8:23 ` Shameerali Kolothum Thodi
2020-12-15 7:49 ` 答复: " wanghuiqiang
2020-12-15 10:00 ` Shameerali Kolothum Thodi
2021-01-06 9:22 ` 答复: " wanghuiqiang
2021-01-07 14:42 ` Shameerali Kolothum Thodi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=846387e4168f1a22638ad07ae670c531@kernel.org \
--to=maz@kernel.org \
--cc=eric.auger@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=shameerali.kolothum.thodi@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).