[libvirt] RFC: extending domcapabilities XML

[Cole Robinson]

Hi all,

There's a couple qemu bits I want to expose in domcapabilities XML, but there
isn't an existing pattern to follow so I'd like to get some feedback first.
Hopefully it can serve as a template for future domcapabilities extensions


1) USB controller models

Not strictly important for my needs, but this is an incremental step. Do we do
some kind of nested XML like

  <controller supported='yes'>
    <type name='usb'/>
      <enum name='model'>
        <value>nec-xhci</value>
        ...
      </enum>
    </type>
  </controller>

Or come up with a unique device-level enum name to track this, like we do for
hostdev subsysType:


  <controller supported='yes'>
    <enum name='usbModel'>
      <value>nec-xhci</value>
      ...
    </enum>
   </controller>


2) new usb ports= attribute

This is for the patches I just sent. There's two questions here: how does XML
look like for a non-enum? Maybe:

  <controller supported='yes'>
    <parameter name='ports' supported='yes'/>
   </controller>

(or maybe <option .../>)

However, ports is only supported for type=usb model=nec-xhci. Do we represent
that? If so what does the XML look like? Do we go crazy nested like:

  <controller supported='yes'>
    <parameter name='type' value='usb'>
      <parameter name='model' value='nec-xhci'/>
        <parameter name='ports' supported='yes'/>
      </parameter>
    </parameter>
   </controller>

But that's kind of intense. It gives the illusion that we can write a parser
to automatically handle additions for introspecting what libvirt supports, but
in practice I don't know if that's ever going to work. Instead I think it's
better to invent new top level strings to represent these types of cases,
rather than try to encode an infinite level of dependency in the XML hierarchy.

  <controller supported='yes'>
    <capability name='usbXHCIPorts' supported='yes'/>
  </controller>

The question then is if the <capability> element is the proper name. Could be
<feature> too but that's quite overloaded in libvirt XML.


3) spice gl

whether spice gl is supported or not is a factor of libvirt version, qemu
version, and spice version that qemu was compiled against, which is a lot of
pieces to track. So exposing it over domcapabilities will be nice. Something like:

<graphics supported='yes'/>
  <enum name='spiceGL'>
    <value>off</value>
    <value>on</value>
  </enum>
</graphics>

Similarly we want to know that virtio-vga has virgl support via <acceleration
accel3d='yes'/>

<video supported='yes'/>
  <enum name='virtioVGAAccel3D'>
    <value>yes</value>
    <value>no</value>
  </enum>
</video>



Comments welcome.

Thanks,
Cole