On Tue, Nov 09, 2010 at 11:29:31AM +0100, Daniel Veillard wrote:
On Tue, Nov 09, 2010 at 04:22:56AM -0500, Jon Masters wrote:
On Thu, 2010-10-21 at 21:52 +0200, Daniel Veillard wrote:
The SMBIOS data are a standardized set of data structures available in the BIOS area of PCs. Those blocks of data describe things like BIOS version informations, machine vendor, model and identifiers, as well as various parts of the machine capability. On a linux machine running dmidecode allows to dump those informations.
Daniel,
Can you tell me if you are (or are willing or planning to) going to implement structure Type 9 of the SMBIOS specification? Specifically, this provides a mapping from the "system slots" (in the chassis) to the PCI devices in the system (as an example), especially where network is concerned (but not limited to that). We are investigating generic solutions for mapping network devices presented by Linux through to the physical devices themselves. So for example, network device eth0 is replaced by eth-slot0-<etc> or lom0, or whatever.
I know virt doesn't have a physical slot, but the ordering of devices does matter very much. Let me know your plans. I am still catching up from LPC last week, so I just skimmed libvirt list. I have a plan to read over your patches soon.
A priori no hypervisor expose any of the type 9 informations. So I don't think using the SMBIOS stucture may actually help solving the device ordering in the guests. My pervious version of the patch which was very close to SMBIOS structure would have allowed to expose those but that's not something we could have used for the hypervisor. Also contrary to the current set of sysinfo informations we won't be able to pick them up from the host in any meaningful way.
The device ordering is still something to be improved but for a given class of devices we tend to assign them PCI slots in the order found in the XML docmain declaration. Right now the order between different classes of devices is hardcoded and that is one point we should be able to improve,
Actually that's not quite correct. If you give a XML config to libvirt without any PCI addresses, libvirt will auto-assign slots in an order that matches QEMU's default auto-assignment. If you want to explicitly control PCI addresses yourself, you can include them in the XML given to libvirt and that will cause libvirt's autoassignment to be skipped. So a mgmt app can guarantee a PCI slot for a given device across all guests if it so desires Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|