| Message ID | 1398956107-7411-1-git-send-email-peter.maydell@linaro.org |
|---|---|
| State | New |
| Headers | show |
On 1 May 2014 15:54, Peter Maydell <peter.maydell@linaro.org> wrote: > Nothing earthshattering here, but it does have the patch which > actually lets us boot an emulated AArch64 CPU on a board... > > thanks > -- PMM > > The following changes since commit 051b9980b99dbfba22ea5f79bd3708d513ae121d: > > Merge remote-tracking branch 'remotes/kraxel/tags/pull-gtk-6' into staging (2014-05-01 14:17:33 +0100) > > are available in the git repository at: > > > git://git.linaro.org/people/pmaydell/qemu-arm.git tags/pull-target-arm-20140501 > > for you to fetch changes up to f42c5c8ec8aa0e15583487ffee62964830751623: > > hw/arm/virt: Add support for Cortex-A57 (2014-05-01 15:25:52 +0100) Applied, thanks. -- PMM
On Thu, May 01, 2014 at 03:54:57PM +0100, Peter Maydell wrote: > Nothing earthshattering here, but it does have the patch which > actually lets us boot an emulated AArch64 CPU on a board... Hi Peter, I have real aarch64 hardware, and I'm trying to find a version of qemu-system-aarch64 which will boot a KVM guest in some form. Upstream qemu fails with a bizarre thread-local storage problem (yes, I've patched glibc to fix the makecontext problem). Is there a qemu tree I should be looking at? Rich.
On 4 May 2014 19:30, Richard W.M. Jones <rjones@redhat.com> wrote: > I have real aarch64 hardware, and I'm trying to find a version of > qemu-system-aarch64 which will boot a KVM guest in some form. > > Upstream qemu fails with a bizarre thread-local storage problem (yes, > I've patched glibc to fix the makecontext problem). > > Is there a qemu tree I should be looking at? Upstream is it. I haven't been testing it for a while though; it's possible it bitrotted while I wasn't looking. thanks -- PMM
On Sun, May 04, 2014 at 07:48:38PM +0100, Peter Maydell wrote: > On 4 May 2014 19:30, Richard W.M. Jones <rjones@redhat.com> wrote: > > I have real aarch64 hardware, and I'm trying to find a version of > > qemu-system-aarch64 which will boot a KVM guest in some form. > > > > Upstream qemu fails with a bizarre thread-local storage problem (yes, > > I've patched glibc to fix the makecontext problem). > > > > Is there a qemu tree I should be looking at? > > Upstream is it. I haven't been testing it for a while though; it's possible > it bitrotted while I wasn't looking. OK, it might be a kernel problem then. This was the issue I was having before: /home/rjones/d/qemu/aarch64-softmmu/qemu-system-aarch64 \ -global virtio-blk-device.scsi=off \ -nodefconfig \ -enable-fips \ -nodefaults \ -display none \ -M virt \ -machine accel=kvm:tcg \ -m 500 \ -no-reboot \ -rtc driftfix=slew \ -global kvm-pit.lost_tick_policy=discard \ -kernel /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/kernel \ -initrd /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/initrd \ -device virtio-scsi-device,id=scsi \ -drive file=/home/rjones/d/libguestfs/tmp/libguestfsHRi4Tt/scratch.1,cache=unsafe,format=raw,id=hd0,if=none \ -device scsi-hd,drive=hd0 \ -drive file=/home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/root,snapshot=on,id=appliance,cache=unsafe,if=none \ -device scsi-hd,drive=appliance \ -device virtio-serial-device \ -serial stdio \ -chardev socket,path=/home/rjones/d/libguestfs/tmp/libguestfsHRi4Tt/guestfsd.sock,id=channel0 \ -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ -append 'panic=1 console=ttyS0 udevtimeout=600 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=screen' Could not access KVM kernel module: Permission denied failed to initialize KVM: Permission denied Back to tcg accelerator. libguestfs: error: appliance closed the connection unexpectedly, see earlier error messages libguestfs: child_cleanup: 0x3b5a1770: child process died libguestfs: sending SIGTERM to process 12438 libguestfs: error: /home/rjones/d/qemu/aarch64-softmmu/qemu-system-aarch64 killed by signal 11 (Segmentation fault), see debug messages above The stack trace in qemu when the segfault occurs is: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000002aae2f17394 in cpu_arm_exec (env=0x3ff8401eed0, env@entry=0x2ab1c978440) at /home/rjones/d/qemu/cpu-exec.c:241 241 current_cpu = cpu; (gdb) print tls__current_cpu Cannot find thread-local storage for LWP 12922, executable file /home/rjones/d/qemu/aarch64-softmmu/qemu-system-aarch64: TLS not supported on this target ... and ^^^ that's the part that makes no sense to me. TLS must surely be supported, so there must be something odd about the compile-time environment. Linux ***.redhat.com 3.13.0-0.rc7.31.***.aarch64.debug #1 SMP Fri May 2 16:55:22 EDT 2014 aarch64 aarch64 aarch64 GNU/Linux glibc-2.19.90-11.fc21.aarch64 gcc-4.9.0-1.fc21.aarch64 Rich.
I think this problem comes from my environment adding -fPIE. In any case, without that flag it doesn't crash in qemu (it kernel panics instead ..) Rich.
On 4 May 2014 19:58, Richard W.M. Jones <rjones@redhat.com> wrote: > On Sun, May 04, 2014 at 07:48:38PM +0100, Peter Maydell wrote: >> On 4 May 2014 19:30, Richard W.M. Jones <rjones@redhat.com> wrote: >> > I have real aarch64 hardware, and I'm trying to find a version of >> > qemu-system-aarch64 which will boot a KVM guest in some form. >> > >> > Upstream qemu fails with a bizarre thread-local storage problem (yes, >> > I've patched glibc to fix the makecontext problem). >> > >> > Is there a qemu tree I should be looking at? >> >> Upstream is it. I haven't been testing it for a while though; it's possible >> it bitrotted while I wasn't looking. > > OK, it might be a kernel problem then. > > This was the issue I was having before: > > /home/rjones/d/qemu/aarch64-softmmu/qemu-system-aarch64 \ > -global virtio-blk-device.scsi=off \ > -nodefconfig \ > -enable-fips \ > -nodefaults \ > -display none \ > -M virt \ > -machine accel=kvm:tcg \ > -m 500 \ > -no-reboot \ > -rtc driftfix=slew \ > -global kvm-pit.lost_tick_policy=discard \ > -kernel /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/kernel \ > -initrd /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/initrd \ > -device virtio-scsi-device,id=scsi \ > -drive file=/home/rjones/d/libguestfs/tmp/libguestfsHRi4Tt/scratch.1,cache=unsafe,format=raw,id=hd0,if=none \ > -device scsi-hd,drive=hd0 \ > -drive file=/home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/root,snapshot=on,id=appliance,cache=unsafe,if=none \ > -device scsi-hd,drive=appliance \ > -device virtio-serial-device \ > -serial stdio \ > -chardev socket,path=/home/rjones/d/libguestfs/tmp/libguestfsHRi4Tt/guestfsd.sock,id=channel0 \ > -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ > -append 'panic=1 console=ttyS0 udevtimeout=600 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=screen' > Could not access KVM kernel module: Permission denied > failed to initialize KVM: Permission denied > Back to tcg accelerator. OK, so you have a kernel (possibly just kernel config) problem here -- this means QEMU got EPERM trying to open /dev/kvm. This isn't going to work for aarch64 at the moment because: * KVM aarch64 currently requires '-cpu host' * '-cpu host' is a KVM only thing that won't work with TCG If you don't enable KVM we don't put 'host' in the CPU list so usually the TCG code can't see it -- however "use KVM but have the init fail" is a path I hadn't considered for getting into TCG with -cpu host. Does this happen if you start with accel=tcg so we're using TCG all the way through? You can also ignore all this in favour of just figuring out why your kernel didn't let us open /dev/kvm... PS: I didn't see a "-cpu something" in your command line; I forget what the default is but it's probably not what you want. > libguestfs: error: appliance closed the connection unexpectedly, see earlier error messages > libguestfs: child_cleanup: 0x3b5a1770: child process died > libguestfs: sending SIGTERM to process 12438 > libguestfs: error: /home/rjones/d/qemu/aarch64-softmmu/qemu-system-aarch64 killed by signal 11 (Segmentation fault), see debug messages above > > The stack trace in qemu when the segfault occurs is: > > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x000002aae2f17394 in cpu_arm_exec (env=0x3ff8401eed0, > env@entry=0x2ab1c978440) at /home/rjones/d/qemu/cpu-exec.c:241 > 241 current_cpu = cpu; > > (gdb) print tls__current_cpu > Cannot find thread-local storage for LWP 12922, executable file /home/rjones/d/qemu/aarch64-softmmu/qemu-system-aarch64: > TLS not supported on this target > > ... and ^^^ that's the part that makes no sense to me. TLS must > surely be supported, so there must be something odd about the > compile-time environment. I think that message is gdb saying that it doesn't support TLS, not that the target architecture doesn't support TLS. How ancient is your gdb? Google suggests that TLS support went into the aarch64 target somewhat after the initial architecture support (though still a year or so ago, so I would have expected it to get in...) thanks -- PMM
On Sun, May 04, 2014 at 08:36:20PM +0100, Peter Maydell wrote: > OK, so you have a kernel (possibly just kernel config) problem > here -- this means QEMU got EPERM trying to open /dev/kvm. Yes for some reason it was 0600. I set it to 0666. > This isn't going to work for aarch64 at the moment because: > * KVM aarch64 currently requires '-cpu host' OK -- I will play with libguestfs to make sure it passes this flag, and try again. Currently waiting for the host (which has panicked again) to be rebooted manually. Thanks again, Rich.
On 4 May 2014 20:45, Richard W.M. Jones <rjones@redhat.com> wrote: > On Sun, May 04, 2014 at 08:36:20PM +0100, Peter Maydell wrote: >> OK, so you have a kernel (possibly just kernel config) problem >> here -- this means QEMU got EPERM trying to open /dev/kvm. > > Yes for some reason it was 0600. I set it to 0666. > >> This isn't going to work for aarch64 at the moment because: >> * KVM aarch64 currently requires '-cpu host' > > OK -- I will play with libguestfs to make sure it passes this flag, > and try again. It should in theory be possible to get -cpu cortex-a57 to work (though I haven't tried it so it's likely missing something trivial); however that will only work if your host CPU is actually a Cortex-A57. For any other host you'll need -cpu host. > Currently waiting for the host (which has panicked > again) to be rebooted manually. If your host has panicked that's a kernel bug :-) (or possibly a hardware bug if you're unlucky). If it does so reproducibly when you prod it with QEMU then you should probably retest with a recent kernel and report it to the kvm-arm mailing list. thanks -- PMM
Nothing earthshattering here, but it does have the patch which actually lets us boot an emulated AArch64 CPU on a board... thanks -- PMM The following changes since commit 051b9980b99dbfba22ea5f79bd3708d513ae121d: Merge remote-tracking branch 'remotes/kraxel/tags/pull-gtk-6' into staging (2014-05-01 14:17:33 +0100) are available in the git repository at: git://git.linaro.org/people/pmaydell/qemu-arm.git tags/pull-target-arm-20140501 for you to fetch changes up to f42c5c8ec8aa0e15583487ffee62964830751623: hw/arm/virt: Add support for Cortex-A57 (2014-05-01 15:25:52 +0100) ---------------------------------------------------------------- target-arm queue: * implement XScale cache lockdown cp15 ops * fix v7M CPUID base register * implement WFE and YIELD as yields for A64 * fix A64 "BLR LR" * support Cortex-A57 in virt machine model * a few other minor AArch64 bugfixes ---------------------------------------------------------------- Edgar E. Iglesias (4): target-arm: Make vbar_write 64bit friendly on 32bit hosts target-arm: A64: Handle blr lr target-arm: A64: Fix a typo when declaring TLBI ops target-arm: Correct a comment refering to EL0 Peter Maydell (4): target-arm: Implement XScale cache lockdown operations as NOPs hw/arm/virt: Create the GIC ourselves rather than (ab)using a15mpcore_priv hw/arm/virt: Put GIC register banks on 64K boundaries hw/arm/virt: Add support for Cortex-A57 Rabin Vincent (1): armv7m_nvic: fix CPUID Base Register Rob Herring (1): target-arm: implement WFE/YIELD as a yield for AArch64 hw/arm/virt.c | 93 ++++++++++++++++++++++++++++++---------------- hw/intc/armv7m_nvic.c | 2 +- target-arm/helper.c | 41 +++++++++++++------- target-arm/op_helper.c | 2 +- target-arm/translate-a64.c | 9 ++++- 5 files changed, 99 insertions(+), 48 deletions(-)