qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: laine@redhat.com, jusual@redhat.com, qemu-devel@nongnu.org
Subject: Re: [RFC 0/5] pc: support user provided NIC naming/indexing
Date: Wed, 13 Jan 2021 07:09:56 -0500	[thread overview]
Message-ID: <20210113064312-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20201222233934.451578-1-imammedo@redhat.com>

On Tue, Dec 22, 2020 at 06:39:29PM -0500, Igor Mammedov wrote:
> 
> Series implements support for 'onboard' naming scheme for network
> interfaces (1), which is based on PCI firmware spec and lets user
> to explicitly specify index that will be used by guest to name
> network interface, ex:
>     -device e1000,acpi-index=33
> should make guest rename NIC name to 'eno33' where 'eno' is default
> prefix for this scheme.
> 
> Hope is that it will allow to simplify launching VMs from
> template disk images with different set VM configurations
> without need to reconfigure guest network intrfaces or
> risk of loosing network connectivity.

Questions:
the spec says:
Assignment of specific device names to multi-function devices installed in expansion
slots, and/or PCI or PCI Express devices that are hot-added to expansion slots in operating system-
environment would be handled in operating system-specific manner, and is not specified via this
specification.

Accordingly, link below says:
" Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)"

to what extend does guest assume the index is for on-board devices?
it seems things work for fedora but how confident are we that this
will keep working.

Further, code seems to only look at the slot level.
According to this, and according to the spec, this does not work with
multifunction devices, does it?


The link you supplied lists another option:
"Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)"
these are under management control already ... 

Also if we ask users to supply the property on the slot then it seems
that the property can be baked into ACPI when it's created instead of
being loaded from host - we can avoid adding new registers, this seems
preferable.  Could someone from management side chime in on whether that
is sufficient?

More questions:

does all this affect windows guests at all?

where does the "acpi index" terminology come from?
the pci firmware spec talks about "instance number", right?



> For more detailed description/examples see patches [3-4/5]
> 
> 1)
>  https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ 
> 
> Git repo for testing:
>    https://github.com/imammedo/qemu/branches acpi-index-rfc
> 
> Igor Mammedov (5):
>   acpi: add aml_to_decimalstring() and aml_call6() helpers
>   tests: acpi: temporary whitelist DSDT changes
>   pci: introduce apci-index property for PCI device
>   pci: acpi: add _DSM method to PCI devices
>   tests: acpi: update expected data files
> 
>  include/hw/acpi/aml-build.h                 |   3 +
>  include/hw/acpi/pci.h                       |   1 +
>  include/hw/acpi/pcihp.h                     |   7 +-
>  include/hw/pci/pci.h                        |   1 +
>  tests/qtest/bios-tables-test-allowed-diff.h |  21 +++++
>  hw/acpi/aml-build.c                         |  28 +++++++
>  hw/acpi/pci.c                               |  84 ++++++++++++++++++++
>  hw/acpi/pcihp.c                             |  25 +++++-
>  hw/i386/acpi-build.c                        |  31 +++++++-
>  hw/pci/pci.c                                |   1 +
>  tests/data/acpi/pc/DSDT                     | Bin 5065 -> 6023 bytes
>  tests/data/acpi/pc/DSDT.acpihmat            | Bin 6390 -> 7348 bytes
>  tests/data/acpi/pc/DSDT.bridge              | Bin 6924 -> 8689 bytes
>  tests/data/acpi/pc/DSDT.cphp                | Bin 5529 -> 6487 bytes
>  tests/data/acpi/pc/DSDT.dimmpxm             | Bin 6719 -> 7677 bytes
>  tests/data/acpi/pc/DSDT.hpbridge            | Bin 5026 -> 5990 bytes
>  tests/data/acpi/pc/DSDT.hpbrroot            | Bin 3084 -> 3177 bytes
>  tests/data/acpi/pc/DSDT.ipmikcs             | Bin 5137 -> 6095 bytes
>  tests/data/acpi/pc/DSDT.memhp               | Bin 6424 -> 7382 bytes
>  tests/data/acpi/pc/DSDT.numamem             | Bin 5071 -> 6029 bytes
>  tests/data/acpi/pc/DSDT.roothp              | Bin 5261 -> 6324 bytes
>  tests/data/acpi/q35/DSDT                    | Bin 7801 -> 7863 bytes
>  tests/data/acpi/q35/DSDT.acpihmat           | Bin 9126 -> 9188 bytes
>  tests/data/acpi/q35/DSDT.bridge             | Bin 7819 -> 7911 bytes
>  tests/data/acpi/q35/DSDT.cphp               | Bin 8265 -> 8327 bytes
>  tests/data/acpi/q35/DSDT.dimmpxm            | Bin 9455 -> 9517 bytes
>  tests/data/acpi/q35/DSDT.ipmibt             | Bin 7876 -> 7938 bytes
>  tests/data/acpi/q35/DSDT.memhp              | Bin 9160 -> 9222 bytes
>  tests/data/acpi/q35/DSDT.mmio64             | Bin 8932 -> 9024 bytes
>  tests/data/acpi/q35/DSDT.numamem            | Bin 7807 -> 7869 bytes
>  tests/data/acpi/q35/DSDT.tis                | Bin 8407 -> 8468 bytes
>  31 files changed, 197 insertions(+), 5 deletions(-)
> 
> -- 
> 2.27.0



  parent reply	other threads:[~2021-01-13 12:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-22 23:39 [RFC 0/5] pc: support user provided NIC naming/indexing Igor Mammedov
2020-12-22 23:39 ` [RFC 1/5] acpi: add aml_to_decimalstring() and aml_call6() helpers Igor Mammedov
2020-12-22 23:39 ` [RFC 2/5] tests: acpi: temporary whitelist DSDT changes Igor Mammedov
2020-12-22 23:39 ` [RFC 3/5] pci: introduce apci-index property for PCI device Igor Mammedov
2020-12-22 23:39 ` [RFC 4/5] pci: acpi: add _DSM method to PCI devices Igor Mammedov
2021-01-13 12:13   ` Michael S. Tsirkin
2021-01-15  0:23     ` Igor Mammedov
2021-01-26 11:16   ` Michael S. Tsirkin
2021-01-26 14:29     ` Igor Mammedov
2020-12-22 23:39 ` [RFC 5/5] tests: acpi: update expected data files Igor Mammedov
2021-01-13 12:09 ` Michael S. Tsirkin [this message]
2021-01-15  1:59   ` [RFC 0/5] pc: support user provided NIC naming/indexing Igor Mammedov
2021-01-17 10:59     ` Michael S. Tsirkin
2021-01-20 12:07       ` Igor Mammedov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210113064312-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=jusual@redhat.com \
    --cc=laine@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).