[libvirt] [PATCH] qemu: assume virtio-memballon without an address to be PCI
When doing XML-to-native conversion, addresses are not assigned. The code building memballon device string assumed they are and returned an error without reporting any error message, leading to: error: An error occurred, but the cause is unknown Assume that address type none means it's a PCI device, as we do for other virtio devices. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=957077 --- This still leaves XML-to-native conversion broken for S390 machines, not just for memballon, but for other virtio devices as well. Should we assign addresses in DomainXMLToNative as well, or just decide which virtio device to add based on the machine type? src/qemu/qemu_command.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 6f6b61b..6e1fff2 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -4083,14 +4083,12 @@ qemuBuildMemballoonDevStr(virDomainMemballoonDefPtr dev, virBuffer buf = VIR_BUFFER_INITIALIZER; switch (dev->info.type) { - case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI: - virBufferAddLit(&buf, "virtio-balloon-pci"); - break; case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW: virBufferAddLit(&buf, "virtio-balloon-ccw"); break; default: - goto error; + virBufferAddLit(&buf, "virtio-balloon-pci"); + break; } virBufferAsprintf(&buf, ",id=%s", dev->info.alias); -- 1.8.1.5
On 04/26/2013 05:51 AM, Ján Tomko wrote:
When doing XML-to-native conversion, addresses are not assigned. The code building memballon device string assumed they are and
s/memballon/memballoon/
returned an error without reporting any error message, leading to: error: An error occurred, but the cause is unknown
Assume that address type none means it's a PCI device, as we do for other virtio devices.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=957077 ---
This still leaves XML-to-native conversion broken for S390 machines, not just for memballon, but for other virtio devices as well. Should we assign addresses in DomainXMLToNative as well, or just decide which virtio device to add based on the machine type?
+++ b/src/qemu/qemu_command.c @@ -4083,14 +4083,12 @@ qemuBuildMemballoonDevStr(virDomainMemballoonDefPtr dev, virBuffer buf = VIR_BUFFER_INITIALIZER;
switch (dev->info.type) { - case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI: - virBufferAddLit(&buf, "virtio-balloon-pci"); - break;
I don't like removing this case.
case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW: virBufferAddLit(&buf, "virtio-balloon-ccw"); break; default: - goto error; + virBufferAddLit(&buf, "virtio-balloon-pci"); + break;
And here, I think we might be better off doing a machine-type query, instead of hard-coding the answer. This is worth fixing for 1.0.5; but I think we need a v2. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Fri, Apr 26, 2013 at 01:51:51PM +0200, Ján Tomko wrote:
When doing XML-to-native conversion, addresses are not assigned. The code building memballon device string assumed they are and returned an error without reporting any error message, leading to: error: An error occurred, but the cause is unknown
Assume that address type none means it's a PCI device, as we do for other virtio devices.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=957077 ---
This still leaves XML-to-native conversion broken for S390 machines, not just for memballon, but for other virtio devices as well. Should we assign addresses in DomainXMLToNative as well, or just decide which virtio device to add based on the machine type?
The XML-to-native API is intended to generate the same command line that libvirt would use, except without any FD passing. If we're to keep that equivalance, then we should be assigning adresses when running DomainXMLToNative too. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (3)
-
Daniel P. Berrange -
Eric Blake -
Ján Tomko