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

[Patrick Siegl]

Am 01.02.2011 12:55, schrieb Daniel P. Berrange:
> On Sun, Jan 30, 2011 at 03:56:15PM +0100, Patrick Siegl wrote:
>> 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
>
That's the output of your recommended commands. You have to pass
urgently  '--enable-kvm' on s390!

boromir:/ # qemu-system-s390x -monitor stdio
The S390 target only works with KVM enabled

boromir:/ # qemu-system-s390x --enable-kvm -monitor stdio
VNC server running on `::1:5900'
QEMU 0.12.50 monitor - type 'help' for more information
(qemu) info qtree
bus: main-system-bus
  type System
  dev: s390-virtio-bridge, id ""
    bus: s390-virtio
      type s390-virtio
      dev: virtio-serial-s390, id ""
        dev-prop: max_ports = 31
        bus: virtio-serial-bus.0
          type virtio-serial-bus
          dev: virtconsole, id ""
            dev-prop: is_console = 1
            dev-prop: chardev = virtcon0
            dev-prop: name = <null>
             dev-prop-int: id: 0
             dev-prop-int: guest_connected: 1
             dev-prop-int: host_connected: 1
      dev: virtio-net-s390, id ""
        dev-prop: mac = 52:54:00:12:34:56
        dev-prop: vlan = 0
        dev-prop: netdev = <null>
(qemu) quit

boromir:/ # qemu-system-s390x --enable-kvm -monitor stdio -nodefconfig
-nodefaults
VNC server running on `::1:5900'
QEMU 0.12.50 monitor - type 'help' for more information
(qemu) info qtree
bus: main-system-bus
  type System
  dev: s390-virtio-bridge, id ""
    bus: s390-virtio
      type s390-virtio
(qemu) quit
boromir:/ #

>> 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.

I think that the output above (of your recommended commands) corresponds
with my assumption.
If you look into the qemu implementation of max_ports in
"qemu-0.13.0/hw/s390-virtio-bus.c" (http://wiki.qemu.org/Download =>
qemu-0.13.0.tar.gz) you will find following which underlines also my
assumption with maximum of 31:

    static VirtIOS390DeviceInfo s390_virtio_serial = {
        .init = s390_virtio_serial_init,
        .qdev.name = "virtio-serial-s390",
        .qdev.alias = "virtio-serial",
        .qdev.size = sizeof(VirtIOS390Device),
        .qdev.props = (Property[]) {
            DEFINE_PROP_UINT32("max_ports", VirtIOS390Device,
max_virtserial_ports,
                               31),
            DEFINE_PROP_END_OF_LIST(),
        },
    };
>> - 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.
Maybe your are right. Test qemu command line shows following:

boromir:/data # qemu-system-s390x -enable-kvm -device
virtio-serial-s390,id=virtio-serial0,max_ports=16,vectors=1,bus=s390-virtio
qemu-system-s390x: -device
virtio-serial-s390,id=virtio-serial0,max_ports=16,vectors=1,bus=s390-virtio:
Property 'virtio-serial-s390.vectors' not found
>> - 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...
>
If you looked at my last patch, there where only few points where I used
the C preprocessor. The point is that I don't know how I should rewrite
the functions for having an arch informationen within it, so that it can
be accepted.

Regards,
Patrick Siegl