Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date:   Mon, 30 Nov 2020 14:56:43 +0000
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
In-Reply-To: <85bb389a75f347d29ab3f75e4cfae060@huawei.com>
References: <20201130102639.7504-1-shameerali.kolothum.thodi@huawei.com>
 <f8a97f360073fa495cae75acc11ecf4f@kernel.org>
 <85bb389a75f347d29ab3f75e4cfae060@huawei.com>
User-Agent: Roundcube Webmail/1.4.9
Message-ID: <846387e4168f1a22638ad07ae670c531@kernel.org>
Precedence: bulk

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...