On Sun, Jan 30, 2011 at 03:56:15PM +0100, Patrick Siegl wrote: > Am 26.01.2011 13:41, schrieb Daniel P. Berrange: > >> On Tue, Jan 25, 2011 at 08:34:03PM +0100, Patrick Siegl wrote: > >>> A few more details for s390x: why you can't set param '-S' and need > >>> '-chardev vc,id=cons -device virtio-serial-s390 -device > >>> virtconsole,chardev=cons' on s390x: > >>> > >>> 1) qemu-system-s390x -M s390-virtio -vnc :0 -enable-kvm -smp 1 -m 1024 > >>> -k de -kernel /boot/image-2.6.34-tue01 -initrd > >>> /boot/initrd-2.6.34-tue01_GUEST -drive file=/data/sle11.img -append > >>> "root=/dev/vda1 rw" > >>> > >>> => screenshot 1 > >>> > >>> 2) qemu-system-s390x -S -M s390-virtio -vnc :0 -enable-kvm -smp 1 -m > >>> 1024 -k de -kernel /boot/image-2.6.34-tue01 -initrd > >>> /boot/initrd-2.6.34-tue01_GUEST -drive file=/data/sle11.img -append > >>> "root=/dev/vda1 rw" > >>> > >>> => screenshot 2 > >>> 3) qemu-system-s390x -M s390-virtio -vnc :0 -enable-kvm -smp 1 -m 1024 > >>> -k de -kernel /boot/image-2.6.34-tue01 -initrd > >>> /boot/initrd-2.6.34-tue01_GUEST -drive file=/data/sle11.img -append > >>> "root=/dev/vda1 rw" -chardev vc,id=cons -device virtio-serial-s390 > >>> -device virtconsole,chardev=cons > >>> > >>> => RUN > >>> > >>> 4) qemu-system-s390x -S -M s390-virtio -vnc :0 -enable-kvm -smp 1 -m > >>> 1024 -k de -kernel /boot/image-2.6.34-tue01 -initrd > >>> /boot/initrd-2.6.34-tue01_GUEST -drive file=/data/sle11.img -append > >>> "root=/dev/vda1 rw" -chardev vc,id=cons -device virtio-serial-s390 > >>> -device virtconsole,chardev=cons > >>> > >>> => screenshot 4 > >> These screenshots are all showing the same thing, but for different > >> reasons. > >> > >> IIUC, there is no 'VGA' graphics adapter in s390 world, hence > >> you need some form of text console. This is what virtio-serial-s390 > >> is providing for you. This does not need to be hardcoded in the > >> QEMU arg generator. You can set this in the XML > >> > >> <console type='vc'> > >> <target type='virtio'/> > >> </console> > >> > >> When you add the '-S' argument this tells QEMU to launch the binary > >> but *NOT* run the guest. When libvirt uses '-S', it launches QEMU > >> runs some monitor commands, and then runs 'cont' to start the > >> guest running. When you're running QEMU manually in your demo > >> above, I assume you never told QEMU to start the CPUs, hence you > >> see the screenshot 4. If you had issued 'cont' on the monitor it > >> would run normally as per example 3. > >> > >> Regards, > >> Daniel > > -- > > libvir-list mailing list > > libvir-list@xxxxxxxxxx > > https://www.redhat.com/mailman/listinfo/libvir-list > > I have overhauled my last patch (for libvirt KVM support on s390x). You > will find the new one as attachment. > There is only one problem, which I can't get fixed. You wrote following: > > "This is expected change, since s390 isn't PCI based, but what > addressing scheme is used for s390 devices to uniquely and > stablly identify them. > > eg, we need to make sure that > > qemu -drive AAA -drive BBB -drive CCC > (monitor) drive_del BBB > > results except same guest visible ABI as > > qemu -drive AAA -drive CCC" > > This is a small problem under s390x, because if you try to add ',addr=' > to a device, qemu prints: "Property '<device>.addr' not found". Can you show the output of # qemu -monitor stdio (qemu) info qtree And also # qemu -monitor stdio -nodefconfig -nodefaults (qemu) info qtree > > There are a few more details: > - netdev isn't supported, because netdev needs param 'bus='. If you try > to run this with BUS s390-virtio, netdev prints, that this is not supported. > (everything should work with virtio, so if you enable '<model > type="virtio"/>', it works fine) This sounds rather like a bug in QEMU, but it might be a mistake in the way libvirt uses netdev. > - You have to set 'ports' for the controller. If you don't do this, the > virtual machine doesn't find VDA and so you can't start it. Maybe this > is because of the flags '-nodefconfig' and '-nodefaults'. The maximum > count of ports is 31 (the qemu implementation kills everything which is > higher than 32). Hmm, qemu has a default value for 'ports' which ought to be being applied regardless of x86 vs s390. > - Also 'vectors' aren't supported for the controller. If you therefor > try to set a value, the virtual machine doesn't start. Not sure why that is. It could be that vectors is something specific to the PCI impl. > - It is not very nice within the libvirt implementation > ('qemu_command.c') when every device gets PCI as address type (the only > way to fix this in a relative moderat time, is to overwrite it with > s390-virtio, if it runs on s390x). Yes, this is the thing that needs the most work to come to a proper solution in libvirt. I'd like to understand more about s390 from the 'info qtree' data requested above to see what we need todo... Daniel -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list