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: Andrew Jones
Subject: Re: [Qemu-devel] [PATCH v3 00/20] GICv3 emulation
Date: Wed, 22 Jun 2016 11:09:37 +0200
User-agent: Mutt/1.5.23.1 (2014-03-12)

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

Thanks,
drew



reply via email to

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