On Thu, May 29, 2014 at 10:32:45AM +0200, Michal Privoznik wrote:
> This piece of information may be useful for management application to
> decide if a domain with a device passthrough can be started on given
> host or not.
>
> Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
> ---
>
> Notes:
> I'm not very happy with the element names, but they're the best I
> could come up with so far. If you have any better suggestion I am
> all ears.
>
> docs/formatcaps.html.in | 8 +++++++-
> docs/schemas/capability.rng | 12 ++++++++++++
> src/conf/capabilities.c | 4 ++++
> tests/capabilityschemadata/caps-qemu-kvm.xml | 2 ++
> tests/capabilityschemadata/caps-test.xml | 2 ++
> tests/capabilityschemadata/caps-test2.xml | 2 ++
> tests/capabilityschemadata/caps-test3.xml | 2 ++
> tests/xencapsdata/xen-i686-pae-hvm.xml | 2 ++
> tests/xencapsdata/xen-i686-pae.xml | 2 ++
> tests/xencapsdata/xen-i686.xml | 2 ++
> tests/xencapsdata/xen-ia64-be-hvm.xml | 2 ++
> tests/xencapsdata/xen-ia64-be.xml | 2 ++
> tests/xencapsdata/xen-ia64-hvm.xml | 2 ++
> tests/xencapsdata/xen-ia64.xml | 2 ++
> tests/xencapsdata/xen-ppc64.xml | 2 ++
> tests/xencapsdata/xen-x86_64-hvm.xml | 2 ++
> tests/xencapsdata/xen-x86_64.xml | 2 ++
> 17 files changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/docs/formatcaps.html.in b/docs/formatcaps.html.in
> index d060a5b..eb8c905 100644
> --- a/docs/formatcaps.html.in
> +++ b/docs/formatcaps.html.in
> @@ -35,6 +35,8 @@ BIOS you will see</p>
> <suspend_disk/>
> <suspend_hybrid/>
> <power_management/>
> + <kvm>true</kvm>
> + <vfio>true</vfio>
> </host></span>
>
> <!-- xen-3.0-x86_64 -->
> @@ -78,7 +80,11 @@ BIOS you will see</p>
> Suspend-to-Disk (S4) and Hybrid-Suspend (a combination of S3
> and S4). In case the host does not support
> any such feature, then an empty <power_management/>
> - tag will be shown. </p>
> + tag will be shown. Then, two elements
> + <code><kvm/></code> and <code><vfio/></code>
> + expose the fact, whether the host supports legacy device
> + passthrough with IOMMU cooperation or newer Virtual function
> + I/O.</p>
> <p>The second block (in blue) indicates the paravirtualization
> support of the Xen support, you will see the os_type of xen
> to indicate a paravirtual kernel, then architecture
> diff --git a/docs/schemas/capability.rng b/docs/schemas/capability.rng
> index d2d9776..3b378eb 100644
> --- a/docs/schemas/capability.rng
> +++ b/docs/schemas/capability.rng
> @@ -48,6 +48,18 @@
> <zeroOrMore>
> <ref name='secmodel'/>
> </zeroOrMore>
> + <element name='kvm'>
> + <choice>
> + <value>false</value>
> + <value>true</value>
> + </choice>
> + </element>
> + <element name='vfio'>
> + <choice>
> + <value>false</value>
> + <value>true</value>
> + </choice>
> + </element>
> </element>
> </define>
>
> diff --git a/src/conf/capabilities.c b/src/conf/capabilities.c
> index 9561ba3..a91f37b 100644
> --- a/src/conf/capabilities.c
> +++ b/src/conf/capabilities.c
> @@ -901,6 +901,10 @@ virCapabilitiesFormatXML(virCapsPtr caps)
> virBufferAddLit(&buf, "</secmodel>\n");
> }
>
> + /* KVM and VFIO features */
> + virBufferAsprintf(&buf, "<kvm>%s</kvm>\n", caps->host.legacyKVMPassthrough ? "true" : "false");
> + virBufferAsprintf(&buf, "<vfio>%s</vfio>\n", caps->host.VFIOPassthrough ? "true" : "false");
Ah, so this is missing from the previous patch.
In fact the splt between this & previous patch is a bit confusing.
I'd expect the previous patch to only change the src/conf/capabilities*
files and generic test cases. While this patch only change the driver
code and driver specific test cases.
So this XML is really trying to provide a list of the valid enumeration
options for the <driver> element of <hostdev> devices. This is quite a
common request for many domain XML elements, so I feel we ought to do
something that is not so ad-hoc here. When we get into this world of
providing info about supported options for devices, we really need to
be able to express this on a fine granularity that the capabilities
XML allows for.
For example, different emulator binaries will support different options,
as will many different architectures, or even different machine types of
virtualization types.
So it feels like we need a new API for this, that accepts info about
the machine we're trying to launch. eg
char * virConnectGetEmulatorCapabilties(virConnectPtr conn,
const char *emulatorbin,
const char *machine,
const char *virttype);
NB I didn't include 'architecture' since that's implicit in the
emulatorbin chosen. The 'char *' return value would be an XML
schema
As for the XML schema, I haven't given it huge thought, but perhaps
something that loosely mirrors the XML schema is desirable.
So for the <hostdev> driver type enum I could imagine starting off with:
<emulatorCapabilities>
<path>/usr/bin/qemyu-system-x86_64</path>
<domain>kvm</domain>
<arch>x86_64</arch>
<machine>pc-1.0</machine>
<devices>
<hostdev>
<driver>
<enum name="driver">
<value>kvm</value>
<value>vfio</value>
</enum>
</driver>
</hostdev>
</devices>
</emulatorCapabilities>
I would expect that the 'maxCpus' hack we stuffed into the existing
capabilities XML would be added to this too eg <vcpus max="120"/>
at the top level
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list