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