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

On Wed, 7 Apr 2021 13:40:03 +0100 Daniel P. Berrangé <berrange(a)redhat.com&gt; 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(a)redhat.com&gt; > > > --- > > > 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.

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.