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 <ler...@redhat.com> 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
