[virt-tools-list] Re: libosinfo - RFC v2

[Daniel P. Berrange]

On Mon, Oct 26, 2009 at 09:05:44PM +0000, Daniel P. Berrange wrote:
> On Sun, Oct 25, 2009 at 03:13:04AM -0400, Arjun Roy wrote:
> > 2. A new type will be added to the library, the osi_hypervisor_t. It will
> > represent information dependent on the choice of hypervisor, such as supported
> > devices. The goal is to query libvirt for hypervisor information, and storing
> > the data in the backing store as a fallback.
> > 
> > In XML, a hypervisor could be represented like this:
> > 
> >   <hypervisor rdf:about="http://qemu.org/qemu-kvm-0.11.0">
> >     <name>KVM</name>
> >     <version>0.11.0</version>
> >     <audio-driver>ac97</audio-driver>
> >     <audio-driver>es1371</audio-driver>
> >     <video-driver>vesa</video-driver>
> >   </hypervisor>
> 
> I think we should consider whether we need to represent drivers as more
> than just strings, and also how we should classify device types. We may
> need to have multiple types against a device, for example a USB device
> may be both an audio & video device at the same time. For that matter we
> probably need to note whether the device is an ISA, PCI or USB device
> here. If you search the PCI IDs list at http://pci-ids.ucw.cz/ for the
> device 'ac97' you'll find about 15 matches, so its not all that great
> as a unique identifier - product/vendor pair is more exact.  Yeah it is
> suboptimal that libvirt uses the string format.
> 
> I hate to say it, but do we perhaps need to have a top level  <device>
> type like ?
> 
>    <device rdf:about="http://pci-ids.ucw.cz/read/PC/1274/5000">
>       <short-id>es1371</short-id>
>       <class type='audio'/>
>       <bus type='pci' vendor='0x1274' product='x05000'/>
>    </device>

Actually I'm wrong in suggesting short-id here - it should be a link
attribute of the relationship between the hypervisor & the device, 
since it is the hypervisor's name of the device. With that the XML
would be like

    <device rdf:about="http://pci-ids.ucw.cz/read/PC/1274/5000">
      <class type='audio'/>
      <bus type='pci' vendor='0x1274' product='x05000'/>
    </device>

> With the hypervisor section cross-referencing the devices
> 
>    <hypervisor rdf:about="http://qemu.org/qemu-kvm-0.11.0">
>      <name>KVM</name>
>      <version>0.11.0</version>
>      <device rdf:resource="http://pci-ids.ucw.cz/read/PC/1002/4382'/>
>      <device rdf:resource="http://pci-ids.ucw.cz/read/PC/1274/5000"/>
>      ....
>    </hypervisor>

And the short name visible thus:

    <hypervisor rdf:about="http://qemu.org/qemu-kvm-0.11.0">
      <name>KVM</name>
      <version>0.11.0</version>
      <device name="ac97" rdf:resource="http://pci-ids.ucw.cz/read/PC/1002/4382'/>
      <device name="es1391' rdf:resource="http://pci-ids.ucw.cz/read/PC/1274/5000"/>
      ....
    </hypervisor>

This allows the possibilty that 'ac97' refers to different devices for 
different hypervisors, nicely taking care of the fact that there are a
great many different devices called 'ac97' and there's no guarentee each
HV provides the same one.

This may all sound over-complex, but bear in mind that all of the 
<device> elements can be completely  auto-generated from the master
PCI ID list, and master USB ID lists published online

  http://pciids.sourceforge.net/
  http://www.linux-usb.org/usb.ids

Though we'd need to manually write the XML for legacy/ISA devices, there
are not many of those to worry about.


We could also potentially auto-generate the list of devices supported by
any Linux based operating system, from the kernel module metadata, eg

  # modinfo iwl3945
  filename:       /lib/modules/2.6.30.8-64.fc11.i686.PAE/kernel/drivers/net/wireless/iwlwifi/iwl3945.ko
  firmware:       iwlwifi-3945-2.ucode
  license:        GPL
  author:         Copyright(c) 2003-2009 Intel Corporation <ilw at linux.intel.com>
  version:        1.2.26kds
  description:    Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux
  srcversion:     444238A1200E1A47282C1D1
  alias:          pci:v00008086d00004227sv*sd*bc*sc*i*
  alias:          pci:v00008086d00004222sv*sd*bc*sc*i*
  alias:          pci:v00008086d00004227sv*sd00001014bc*sc*i*
  alias:          pci:v00008086d00004222sv*sd00001044bc*sc*i*
  alias:          pci:v00008086d00004222sv*sd00001034bc*sc*i*
  alias:          pci:v00008086d00004222sv*sd00001005bc*sc*i*
  depends:        mac80211,iwlcore,cfg80211,lib80211
  vermagic:       2.6.30.8-64.fc11.i686.PAE SMP mod_unload 686 
  parm:           antenna:select antenna (1=Main, 2=Aux, default 0 [both]) (int)
  parm:           disable:manually disable the radio (default 0 [radio on]) (int)
  parm:           swcrypto:using software crypto (default 1 [software])
   (int)
  parm:           debug:debug output mask (uint)
  parm:           disable_hw_scan:disable hardware scanning (default 0) (int)
  parm:           queues_num:number of hw queues. (int)
  parm:           fw_restart3945:restart firmware in case of error (int)


Those 'alias' lines are the ones we need - they encode the PCI vendor and
product IDs. It ought to be possible to provide a script that can  extract
all that data for us.

I'd like to think we can find a way to auto-generate the data for QEMU
too - there's already ability to run 'qemu -device ?' to get list of
short-ids - if we can jst get the PCI IDs in there too we'd be sorted.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|