[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC v1] hw/smbios: support for type 41 (onboard devices extended in
From: |
Vincent Bernat |
Subject: |
Re: [RFC v1] hw/smbios: support for type 41 (onboard devices extended information) |
Date: |
Tue, 30 Mar 2021 15:08:37 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
❦ 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)