[libvirt] [PATCH] SpaprVio addresses are 32-bit, not 64-bit

[Daniel P. Berrangé]

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