[libvirt PATCH 1/6] conf: add support for <acpi index='NNN'/> for PCI devices

[Daniel P. Berrangé]

On Wed, Apr 07, 2021 at 10:23:37PM +0200, Igor Mammedov wrote:
> On Wed, 7 Apr 2021 13:40:03 +0100
> Daniel P. Berrangé <berrange at redhat.com> wrote:
> 
> > On Wed, Apr 07, 2021 at 09:17:36AM +0200, Peter Krempa wrote:
> > > On Tue, Apr 06, 2021 at 16:31:32 +0100, Daniel Berrange wrote:  
> > > > PCI devices can be associated with a unique integer index that is
> > > > exposed via ACPI. In Linux OS with systemd, this value is used for
> > > > provide a NIC device naming scheme that is stable across changes
> > > > in PCI slot configuration.
> > > > 
> > > > Signed-off-by: Daniel P. Berrangé <berrange at redhat.com>
> > > > ---
> > > >  docs/formatdomain.rst         |  6 +++
> > > >  docs/schemas/domaincommon.rng | 73 +++++++++++++++++++++++++++++++++++
> > > >  src/conf/device_conf.h        |  3 ++
> > > >  src/conf/domain_conf.c        | 12 ++++++
> > > >  4 files changed, 94 insertions(+)
> > > > 
> > > > diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
> > > > index 7ba32ea9c1..5db0aac77a 100644
> > > > --- a/docs/formatdomain.rst
> > > > +++ b/docs/formatdomain.rst
> > > > @@ -4363,6 +4363,7 @@ Network interfaces
> > > >         <mac address='52:54:00:5d:c7:9e'/>
> > > >         <boot order='1'/>
> > > >         <rom bar='off'/>
> > > > +       <acpi index='4'/>
> > > >       </interface>
> > > >     </devices>
> > > >     ...
> > > > @@ -4389,6 +4390,11 @@ when it's in the reserved VMware range by adding a ``type="static"`` attribute
> > > >  to the ``<mac/>`` element. Note that this attribute is useless if the provided
> > > >  MAC address is outside of the reserved VMWare ranges.
> > > >  
> > > > +:since:`Since 7.3.0`, one can set the ACPI index against network interfaces.
> > > > +With some operating systems (eg Linux with systemd), the ACPI index is used
> > > > +to provide network interface device naming, that is stable across changes
> > > > +in PCI addresses assigned to the device.  
> > > 
> > > Any range limits or uniqueness requirements worth mentioning?  
> > 
> > Yes, its required to be unique and below (16 * 1024 - 1) because
> > for some reason QEMU chose to artificially limit its value to
> > match systemd's limit. This is a bit dubious IMHO, as the host
> > should not enforce policy for things that are decided by the
> > guest.
> dropping limit would just postpone error till guest boots
> with effect that 'oboard' naming won't be used and systemd
> will fallback to the next available method.

That's no big deal - the user will easily see this and change their
config. It is a mere docs problem at most.

> Given that systemd is the sole known user of this feature,
> it seemed better to me to error out at QEMU start rather than
> waiting till guests boots and let user figure out what's wrong.
> 
> If we find another user for the feature that supports full range
> we can drop limit easily without any compat issues.

There must be other users of this feature, given that we're using
a facility that is part of a formal ACPI specification that existed
before systemd had this feature. Given that I think it is very
bad practice to apply a limit host side that's tied to a single
guest usecase, regardless of whether we happen to know about the
other users. We're basically creating a bug in QEMU upfront that
doesn't need to exist.

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