[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PULL 00/10] target-arm queue
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [PULL 00/10] target-arm queue |
Date: |
Sun, 4 May 2014 20:36:20 +0100 |
On 4 May 2014 19:58, Richard W.M. Jones <address@hidden> wrote:
> On Sun, May 04, 2014 at 07:48:38PM +0100, Peter Maydell wrote:
>> On 4 May 2014 19:30, Richard W.M. Jones <address@hidden> 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,
> address@hidden) 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
- [Qemu-devel] [PULL 09/10] hw/arm/virt: Put GIC register banks on 64K boundaries, (continued)
- [Qemu-devel] [PULL 09/10] hw/arm/virt: Put GIC register banks on 64K boundaries, Peter Maydell, 2014/05/01
- [Qemu-devel] [PULL 01/10] target-arm: Implement XScale cache lockdown operations as NOPs, Peter Maydell, 2014/05/01
- [Qemu-devel] [PULL 06/10] target-arm: A64: Fix a typo when declaring TLBI ops, Peter Maydell, 2014/05/01
- [Qemu-devel] [PULL 03/10] target-arm: implement WFE/YIELD as a yield for AArch64, Peter Maydell, 2014/05/01
- [Qemu-devel] [PULL 04/10] target-arm: Make vbar_write 64bit friendly on 32bit hosts, Peter Maydell, 2014/05/01
- [Qemu-devel] [PULL 10/10] hw/arm/virt: Add support for Cortex-A57, Peter Maydell, 2014/05/01
- Re: [Qemu-devel] [PULL 00/10] target-arm queue, Peter Maydell, 2014/05/02
- Re: [Qemu-devel] [PULL 00/10] target-arm queue, Richard W.M. Jones, 2014/05/04
- Re: [Qemu-devel] [PULL 00/10] target-arm queue, Richard W.M. Jones, 2014/05/04