qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 00/20] GICv3 emulation


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH v3 00/20] GICv3 emulation
Date: Wed, 22 Jun 2016 17:23:09 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1

On 06/22/16 11:09, Andrew Jones wrote:
> On Wed, Jun 22, 2016 at 04:27:35PM +0800, Shannon Zhao wrote:
>>
>>
>> On 2016/6/22 15:43, Andrew Jones wrote:
>>> On Wed, Jun 22, 2016 at 09:42:29AM +0800, Shannon Zhao wrote:
>>>>>
>>>>>
>>>>> On 2016/6/22 3:53, Peter Maydell wrote:
>>>>>>> On 21 June 2016 at 20:45, Laszlo Ersek <address@hidden> wrote:
>>>>>>>>>>> On 06/21/16 19:21, Peter Maydell wrote:
>>>>>>>>>>>>>>> and add a note I forgot to mention: my primary hypothesis is 
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> the problem here is "guest does not write to the GICD_IGROUPR 
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> GICR_IGROUPR registers to program the interrupts it's using as
>>>>>>>>>>>>>>> group 1, but still expects to get IRQs rather than FIQs".
>>>>>>>>>>>
>>>>>>>>>>> ... and it (or whatever else is the root cause) seems to manifest in
>>>>>>>>>>> either the Stall() UEFI boot service, or in UEFI timer events. (This
>>>>>>>>>>> seems to follow from the last debug log entry from Shannon:
>>>>>>>>>>>
>>>>>>>>>>> [Bds]BdsWait(3)..Zzzz...
>>>>>>>>>>> )
>>>>>>>>>>>
>>>>>>>>>>> ... Just to make it clear: does it reproduce with KVM? Or is that
>>>>>>>>>>> untested perhaps (due to lack of GICv3 hardware e.g.)?
>>>>>>> Upthread Shannon said it worked with KVM enabled. Note that
>>>>>>> KVM's GICv3 emulation is incorrect in that it does not support
>>>>>>> interrupt groups, so all interrupt groups are Group 1 and
>>>>>>> generate IRQ even if the guest doesn't do anything to
>>>>>>> configure them.
>>>>> It does work with KVM enabled. It also works with UEFI and the upstream
>>>>> linux kernel while it doesn't work with UEFI and a FreeBSD guest since
>>>>> the FreeBSD doesn't correctly set the IGROUPR, I think.
>>> Doesn't appear to be FreeBSD specific, as I'm using a Linux kernel and
>>> can reproduce. Besides, it doesn't even make it to grub.
>>>
>>>>>
>>>>> I can't find the commit ID of the UEFI I use but I used the upsream
>>>>> codes of June 15.
>>>>> Andrew, I suggest you use the QEMU mainline which includes the GICv3
>>>>> emulation and the guest kernel with the commit 7c9b973061.
>>> Yeah, I hadn't noticed that gicv3 made it to mainline. I've switched
>>> to that now. My guest kernel does have 7c9b973061 (I backported it to
>>> the RHELSA kernel)
>>
>> I just used a new UEFI binary which is built on 8f88f02 and the upstream
>> linux kernel. It boots as well.
>> Could you try the upstream linux kernel?
> 
> It doesn't even make it to grub, so the kernel doesn't matter. I'm getting
> the impression that you're using both UEFI and -kernel to boot, when
> booting Linux, but not when booting FreeBSD. Indeed, if I add -kernel to
> my cmdline, then I can boot the RHELSA kernel as well. So this looks like
> an AAVMF launching grub issue (or just a grub issue).

The difference is that with -kernel, the firmware doesn't go as far into
the BDS code as without it. The firmware code that exposes the GICv3
configuration issue is not reached when you launch QEMU with -kernel.

The GICv3 is incorrectly configured just the same, but with -kernel, the
first thing that would expose it is the kernel, and (AIUI) Peter fixed
that already.

Anyway, please see / test Ard's edk2 patch that you all were CC'd on.

Thanks!
Laszlo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]