On 04.04.2011, at 00:43, Alexander Graf wrote: > > On 04.04.2011, at 00:37, Aurelien Jarno wrote: > >> On Tue, Mar 29, 2011 at 03:29:27PM +0200, Alexander Graf wrote: >>> We've had support for running s390x guests with KVM for a >>> while now. This patch set also enables support for running >>> s390x guests in system as well as linux-user mode in emulation! >>> >>> Within this scope, I again want to stress that this is _not_ >>> supposed to replace Hercules - the s390 emulator - in any way. >>> The only target supported by qemu is Linux. You can only run >>> Linux applications with linux-user emulation and Linux guest OSs >>> with the system emulation. All the device logic (and 24 bit mode) >>> for running legacy stuff is missing. Use Hercules for those! >>> >>> I have successfully run the following guest OSs: >>> >>> - SUSE Linux Enterprise Server 11 SP1 >>> - Debian Lenny >>> >>> Both of which work just fine on x86_64 and ppc hosts. Other hosts >>> should also work. The only thing that did not work for me is network. >>> Somehow networking only works with KVM enabled, so there is probably >>> some bug involved still. >>> >>> Either way - rejoice! As with this patch set you can finally fulfill >>> your mainframe desires on your local workstation. And - most importantly - >>> finally test patches to virtio against s390! >>> >>> For images, I'm hoping for Aurelien to provide Debian images that run >>> in qemu. Other distributions only provide S390x target support in their >>> enterprise variants, keeping me from redistributing images :(. >>> >>> If you're trying to get things rolling yourself, make sure to use a >>> recent kernel that has support for the virtio architecture and virtio >>> console support - otherwise you won't see output. >>> >>> The linux user mode emulation part only support 64bit binaries, so >>> running Debian binaries with that one is out of question for now. Use >>> the system emulation mode if you really need to run Debian binaries. >>> >>> For the lazy ones: >>> >>> git://repo.or.cz/qemu/agraf.git s390-tcg-v2 >>> >>> v1 -> v2: >>> >>> - fix broken s390-virtio-serial >>> - fix broken s390 kvm target >>> - always set 64bit flag for s390x binaries in elf loader >>> - remove redundant EXECUTE_SVC >>> - advance psw.addr in syscall execution path >>> - remove FPReg definition >>> - add descriptions to more cc_ops >>> - add comment on time2tod >>> - describe EXCP_EXT >>> - use new clock syntax >>> - use float_chs >>> - use float compare built-ins >>> - remove redundant EXECUTE_SVC >>> - don't pass env into DisasContext >>> - remove if 0'd code >>> - truncate at 80 chars >>> - enable disas debug by default (-d in_asm) >>> - remove explicit psw.addr advancing on SVC >>> >>> Alexander Graf (14): >>> Only build ivshmem when CONFIG_PCI && CONFIG_KVM >>> virtio: use generic name when possible >>> s390x: fix KVM target >>> s390x: fix s390-virtio-serial >>> s390x: Enable s390x-softmmu target >>> s390x: Dispatch interrupts to KVM or the real CPU >>> s390x: Adjust GDB stub >>> s390x: virtio machine storage keys >>> s390x: Prepare cpu.h for emulation >>> s390x: helper functions for system emulation >>> s390x: Implement opcode helpers >>> s390x: Adjust internal kvm code >>> s390x: translate engine for s390x CPU >>> s390x: build s390x by default >>> >>> Ulrich Hecht (5): >>> s390x: Enable disassembler for s390x >>> s390x: Enable nptl for s390x >>> s390x: enable CPU_QuadU >>> s390x: s390x-linux-user support >>> linux-user: define a couple of syscalls for non-uid16 targets >>> >>> Makefile.target | 8 +- >>> blockdev.c | 2 +- >>> configure | 3 + >>> cpu-all.h | 2 +- >>> cpu-exec.c | 8 + >>> default-configs/s390x-linux-user.mak | 1 + >>> disas.c | 6 + >>> gdbstub.c | 8 +- >>> hw/s390-virtio-bus.c | 18 +- >>> hw/s390-virtio-bus.h | 4 +- >>> hw/s390-virtio.c | 21 +- >>> hw/virtio-pci.c | 3 + >>> linux-user/elfload.c | 19 + >>> linux-user/main.c | 83 + >>> linux-user/s390x/syscall.h | 25 + >>> linux-user/s390x/syscall_nr.h | 349 +++ >>> linux-user/s390x/target_signal.h | 26 + >>> linux-user/s390x/termbits.h | 283 ++ >>> linux-user/signal.c | 314 +++ >>> linux-user/syscall.c | 143 +- >>> linux-user/syscall_defs.h | 56 +- >>> s390x.ld | 194 ++ >>> scripts/qemu-binfmt-conf.sh | 4 +- >>> target-s390x/cpu.h | 770 +++++- >>> target-s390x/exec.h | 20 + >>> target-s390x/helper.c | 581 ++++- >>> target-s390x/helpers.h | 151 + >>> target-s390x/kvm.c | 62 +- >>> target-s390x/op_helper.c | 2880 +++++++++++++++++++- >>> target-s390x/translate.c | 5116 >>> +++++++++++++++++++++++++++++++++- >>> vl.c | 6 +- >>> 31 files changed, 11005 insertions(+), 161 deletions(-) >>> create mode 100644 default-configs/s390x-linux-user.mak >>> create mode 100644 linux-user/s390x/syscall.h >>> create mode 100644 linux-user/s390x/syscall_nr.h >>> create mode 100644 linux-user/s390x/target_signal.h >>> create mode 100644 linux-user/s390x/termbits.h >>> create mode 100644 s390x.ld >>> create mode 100644 target-s390x/helpers.h >>> >> >> I haven't found time to look at the full series, but I have already >> merged patches 1 to 7. They already make sense to have, and it will >> prevent you to respin them in the next version (if any). I'll try to >> review and merge the remaining patches later this week. > > Ah, sorry. I've started to work on v3 and then realized that bash doesn't > work in linux-user anymore. I tracked it down to the rebase from my > development snapshot to current git where things broke, so it's either > breakage in qemu proper or in the way s390 emulation interacts. > > Something broke in the do_sendrecvmsg context: msgp->msg_controllen went from > 0x14 to some garbage, resulting in a huge stack allocation which means that > on first stack access, the while thing goes boom. If I nop out do_sendrcvmsg > bash still works. I haven't been able to track that one down completely yet.
Ok, I tracked down that one to a misaligned guest structure. > The other thing I've realized thanks to Richard is that -R doesn't work at > all :). As soon as I pass it in, things start to fall apart. Turns out this is a generic bug. Somehow sigaltstack seems to leak the resolved pointers into the guest, so that when a signal happens we set the stack pointer to the virtual address at which point any stack access goes to an address with some offset, blowing everything up. The easiest test case for this I've found is running bash. I also verified that the same happens for x86_64-linux-user. Alex
