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 :|