[libvirt] Rudimentary (basic) s390x architecture functions for libvirt

[Daniel P. Berrange]

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 at redhat.com
> > 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