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, 15 Jun 2016 11:20:23 +0200
User-agent: Mutt/1.5.23.1 (2014-03-12)

On Wed, Jun 15, 2016 at 04:53:35PM +0800, Shannon Zhao wrote:
> 
> 
> On 2016/6/14 22:38, Peter Maydell wrote:
> > This series implements emulation of the GICv3 interrupt controller.
> > It is based to some extent on previous patches from Shlomo and
> > Pavel, but the bulk of it has turned out to be new code. (The
> > combination of changing the underlying data structures, adding
> > support for TrustZone and implementing proper GICv3 behaviour rather
> > than borrowing fragments of GICv2 emulation code meant there wasn't
> > much left to reuse.) I've tried to reflect this in the various
> > authorship credits on the patches, but please let me know if you
> > feel I got anything miscredited one way or the other.
> > 
> > Key points about the GICv3 emulated here:
> >  * "non-legacy" only, ie system registers and affinity routing
> >  * TrustZone is implemented
> >  * no virtualization support
> >  * only the "core" GICv3, so no LPI support (via ITS or otherwise)
> >  * no attempt to work around the Linux guest kernel bug fixed
> >    in commit 7c9b973061b0 (so you need that fix for your guest to
> >    boot with this GICv3)
> Hi Peter,
> 
> I have another test with a freebsd guest. When I specify gic-version=3
> at the QEMU command line, the guest can't start. But with gic-version=2
> it's fine. And if I use gic-version=3 with kvm, the guest boots well too.
> 
> It hangs with below log:
> [Bds]=============Begin Load Options Dumping ...=============
>   Driver Options:
>   SysPrep Options:
>   Boot Options:
>     Boot0000: UiApp              0x0109
>     Boot0001: EFI Internal Shell                 0x0001
>     Boot0002: UEFI Misc Device           0x0001
>     Boot0003: UEFI Misc Device 2                 0x0001
>     Boot0004: UEFI Misc Device 3                 0x0001
>     Boot0005: UEFI PXEv4 (MAC:525400123456)              0x0001
>   PlatformRecovery Options:
>     PlatformRecovery0000: Default PlatformRecovery               0x0001
> [Bds]=============End Load Options Dumping=============
> [Bds]BdsWait ...Zzzzzzzzzzzz...
> [Bds]BdsWait(3)..Zzzz...
> 
> 
> The QEMU command line is:
> qemu-system-aarch64 \
> -m 4096M -cpu cortex-a57 -M virt,gic-version=3 -smp 1 \
> -bios QEMU_EFI.fd -serial telnet::4445,server -nographic \
> -drive
> if=none,file=FreeBSD-11.0-ALPHA3-arm64-aarch64-20160528-r301815.qcow2,id=hd0
> \
> -device virtio-blk-device,drive=hd0 \
> -device virtio-net-device,netdev=net0 \
> -netdev user,id=net0
> 
> The QEMU_EFI.fd is built on edk2 commit ID 8f88f02 and the disk Image
> file is downloaded from
> http://www2.tw.freebsd.org/FreeBSD/snapshots/VM-IMAGES/11.0-ALPHA3/aarch64/20160528/FreeBSD-11.0-ALPHA3-arm64-aarch64-20160528-r301815.qcow2.xz

There may be a bug in the freebsd kernel. Maybe they need the equivalent
of Linux's 7c9b973061 "irqchip/gic-v3: Configure all interrupts as
non-secure Group-1". You could add the hack back that was in the initial
posting of this series to see if that "fixes" things.

drew



reply via email to

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