qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Vincent Bernat <vincent@bernat.ch>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [RFC v1] hw/smbios: support for type 41 (onboard devices extended information)
Date: Tue, 30 Mar 2021 15:08:37 +0200	[thread overview]
Message-ID: <m3ft0ceqlm.fsf@bernat.ch> (raw)
In-Reply-To: <YGL++3NLdBeN7j4f@redhat.com> ("Daniel P. Berrangé"'s message of "Tue, 30 Mar 2021 11:35:39 +0100")

 ❦ 30 mars 2021 11:35 +01, Daniel P. Berrangé:

>> If network devices are present in this table, by default, udev will
>> name the corresponding interfaces enoX, X being the instance number.
>> Without such information, udev will fallback to using the PCI ID and
>> this usually gives ens3 or ens4. This can be a bit annoying as the
>> name of the network card may depend on the order of options and may
>> change if a new PCI device is added earlier on the commande line.
>> Being able to provide SMBIOS type 41 entry ensure the name of the
>> interface won't change and helps the user guess the right name without
>> booting a first time.
>> 
>> This can be invoked with:
>> 
>>     $QEMU -netdev user,id=internet
>>           -device virtio-net-pci,mac=50:54:00:00:00:42,netdev=internet \
>>           -smbios type=41,designation=Onboard LAN,instance=1,kind=ethernet,pci=0000:00:09.0
>> 
>> Which results in the guest seeing dmidecode data and the interface
>> exposed as "eno1":
>> 
>>     $ dmidecode -t 41
>>     # dmidecode 3.3
>>     Getting SMBIOS data from sysfs.
>>     SMBIOS 2.8 present.Handle 0x2900, DMI type 41, 11 bytes
>>     Onboard Device
>>             Reference Designation: Onboard LAN
>>             Type: Ethernet
>>             Status: Enabled
>>             Type Instance: 1
>>             Bus Address: 0000:00:09.0
>>     $ udevadm info -p /sys/class/net/eno1 | grep ONBOARD
>>     E: ID_NET_NAME_ONBOARD=eno1
>>     E: ID_NET_LABEL_ONBOARD=Onboard LAN
>> 
>> The original plan was to directly provide a device and populate "kind"
>> and "pci" from the device. However, since the SMIBIOS tables are built
>> during argument evaluation, the information is not yet available.
>> I would welcome some guidance on how to implement this.
>
> I'm not sure I see the problem you're describing here, could
> you elaborate ?
>
> I see SMBIOS tables are built by  smbios_get_tables() method.
> This is called from qemu_init(), after all arguents have been
> processed and devices have been created.

OK, I was mistaken. I'll try to retrieve the information here then.

> It seems like this should allow SMBIOS tables to be auto-populated
> from the NICs listed in -device args previously.
>
>
> Note, if we're going to auto-populate the SMBIOS type 41 tabes
> from -device args, then we'll need to make this behaviour
> configurable via a property, so that we can ensure this only
> applies to new machine types.

I didn't plan for something automatic, just being able to specify a PCI
device in the -smbios arguments and have the PCI location automatically
filled from that.
-- 
Keep it simple to make it faster.
            - The Elements of Programming Style (Kernighan & Plauger)


      reply	other threads:[~2021-03-30 13:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-28 20:57 [RFC v1] hw/smbios: support for type 41 (onboard devices extended information) Vincent Bernat
2021-03-29  1:03 ` no-reply
2021-03-30 10:35 ` Daniel P. Berrangé
2021-03-30 13:08   ` Vincent Bernat [this message]

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=m3ft0ceqlm.fsf@bernat.ch \
    --to=vincent@bernat.ch \
    --cc=berrange@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).