11:18 a.m.
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