From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39832) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFjzq-0000jc-TB for qemu-devel@nongnu.org; Wed, 22 Jun 2016 11:23:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFjzm-0003bH-Sc for qemu-devel@nongnu.org; Wed, 22 Jun 2016 11:23:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34663) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFjzm-0003av-KR for qemu-devel@nongnu.org; Wed, 22 Jun 2016 11:23:14 -0400 References: <20160621151202.hbwpqyvmbnno3yfy@hawk.localdomain> <20160621171557.uq6ellpqom43kanz@hawk.localdomain> <20160621171813.hbzbzx3ojys2tkts@hawk.localdomain> <5c504e1b-f311-272a-724f-2182349c3cd1@redhat.com> <5769ED05.2050409@huawei.com> <20160622074342.navvazli3ekal3sf@hawk.localdomain> <576A4BF7.4050501@huawei.com> <20160622090937.euit6qm77hvemwkn@hawk.localdomain> From: Laszlo Ersek Message-ID: <3901e25b-8c0e-b5a7-4a3f-cd94c06695be@redhat.com> Date: Wed, 22 Jun 2016 17:23:09 +0200 MIME-Version: 1.0 In-Reply-To: <20160622090937.euit6qm77hvemwkn@hawk.localdomain> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 00/20] GICv3 emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrew Jones , Shannon Zhao Cc: Peter Maydell , Ard Biesheuvel , Shlomo Pongratz , Shlomo Pongratz , Patch Tracking , Pavel Fedin , QEMU Developers , Shannon Zhao , Christoffer Dall 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 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