[libvirt PATCH v2 2/3] conf: support firmware ISA debug console

[Daniel P. Berrangé]

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