[libvirt] RFC: extending domcapabilities XML
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