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)
prev parent 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).