On 05/18/2016 07:53 AM, Cole Robinson wrote:
Kind of. Prior to patch #2, the test suite output was correct (no addresses), it's what we were returning via domxml-from-native. After patch #2, the test suite output was wrong for all real world usage; it didn't change because it was only hitting a !QEMU_CAPS_DEVICE code path So the potentially contentious bit is that patch #2 changes domxml-from-native output to contain addresses, however that's exactly the same result that will happen when the XML would eventually be defined anyways, so it's effectively the same result as pre-patch #2 anyways. If we think of domxml-from-native as telling the user 'this is exactly what libvirt thinks that command line is' then we are now giving more accurate results Let me know if that still warrants the ACK
My opinion is that this is a change for the better. While it is true that this could lead to XML that potentially shows different PCI addresses than what would have been auto-assigned by qemu when presented with the original commandline, it *is* showing the addresses that would be auto-allocated by libvirt if you had fed the "un-addressified" XML to libvirt - so at least the user will get a warning rather than being surprised at runtime. And it's not as if the output of domxml-from-native has ever produced anything even close to the correct XML in any real world situation. (dreadkopp in public #virt pastebin'ed an example last night - 90% of it was translated directly into <qemu:arg> elements).
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list