On Mon, Jul 01, 2019 at 10:35:17AM +1000, David Gibson wrote: > On Fri, Jun 14, 2019 at 01:45:24PM +0200, Andrea Bolognani wrote: > > On Tue, 2019-06-04 at 11:38 +1000, David Gibson wrote: > > > spapr-vio addresses are used on POWER platform qemu guests, which are > > > based > > > on the PAPR specification. PAPR specifies a number of virtual devices > > > (but > > > not virtio protocol) which are addressed in an abstract namespace. > > > > > > Currently, libvirt encodes these addresses as 64-bit values. This is not > > > correct: spapr-vio addresses are, and always have been 32-bit. That's > > > true > > > both by the PAPR specification and the qemu implementation. > > > > > > Therefore, change this in libvirt. > > > > > > This looks like it would be a breaking change, but it actually isn't. > > > Because these have always been 32-bit at the lower levels, any attempt to > > > use a value here > 0xffffffff would always have failed in any case, this > > > will just make it fail earlier and more clearly. > > > > Thanks for providing this patch, and sorry for taking a while to get > > back to you about it. > > > > Unfortunately there's one major issue with your approach: even though > > it's true that a spapr-vio address that can't be represented as a > > 32-bit value would always have been rejected by QEMU and so the guest > > would never have been able to start, refusing to parse the value > > altogether would cause such a guest to disappear completely from > > libvirt. We don't consider this to be acceptable, because we want to > > give users a chance to fix their guests that doesn't involve poking > > at the filesystem behind libvirt's back.
I missed this when it was first posted, but I would have said that we really don't need to consider this scenario. This is a valid thing to worry about *if* the previous config was actually something a person would have used in the past. In this case though there's no way the guest could ever have worked with value > 0xffffffff. At the very most they could have a defined XML config that they might have tried & failed to use. We would have been justified in just changing the parser to use a 32-bit int straight away. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
