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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list