qemu-devel
[Top][All Lists]
Advanced

[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)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]