On Mon, Jul 01, 2019 at 11:02:55AM +0200, Andrea Bolognani wrote: > On Mon, 2019-07-01 at 09:50 +0100, Daniel P. Berrangé wrote: > > 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: > > > > 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. > > In the past we've bent over backwards to keep guest configurations > from failing to parse, a good example being network interface models > that never existed in QEMU, and I believe Cole's recent changes in > that area made sure such configurations can still be parsed and only > fail to validate for this very reason. The reason we were careful with network models is that we did not have confidence that we have listed all known NIC models in our enum, most especially for non-x86 archs where QEMU has alot of NIC models. Thus there was a reasonable chance we would break an existing valid working guest configuration & thus we needed to be particularly carefult not to cause a regression. > How is this situation different? What did I miss? There is no way this guest configuration could ever have worked. It was always an error before the proposed change, so we would not be breaking anything that was ever expected to work. 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
