On Wed, Feb 02, 2022 at 07:47:37AM -0800, Andrea Bolognani wrote: > On Wed, Feb 02, 2022 at 03:38:59PM +0000, Daniel P. Berrangé wrote: > > On Wed, Feb 02, 2022 at 06:46:25AM -0800, Andrea Bolognani wrote: > > > I think it would still make sense to reflect QEMU's current default > > > in the XML, which would make sure that the same input XML results in > > > the same device even if QEMU decides to change its defaults later on. > > > > We don't do that for any existing ISA devices AFAICT, so I'm not finding > > a compelling reason to treat isa-debugcon as special. > > Go ahead with the patches as they are then. Maybe I will try to > implement this idea for all ISA devices at some point :) FWIW the reason it is important for PCI of course is that PCI is highly dynamic at runtime with ability to hotplug/unplug, which means addresses aren't predictable in the next launch unless you fixate them in libvirt upfront. For ISA being entirely statically defined at cold boot, the only think that can affect the address information (IRQ, IO Port) on next boot is a change in QEMU machine type, which is already solved by versioning them. If the argument is "the machine type could change and we should not let that influence guest future boots" then that means we shouldn't have machine types at all, and be explicitly representing every possible hardware property a machine type implies instead. IMHO the only benefit from exposing the ISA address defaults in the XML is as a means of transparency for users, so they can gain insight into the hardware defaults. Effectively libvirt would be documenting QEMU's machine type in doing that. 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 :|
