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.
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. Thanks, -- Shannon
