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