On 30.05.2014 11:11, Daniel P. Berrange wrote:
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);
What's this virttype argument?
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.
the XML schema? You mean the capabilities XML schema?
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>
I find this misleading. I mean, why kvm and vfio is under
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
So let me see if I understand correctly. To represent
emulatorCapabilities in memory we need another structure, say:
typedef struct _virEmulatorCapabilities virEmulatorCapabilities;
typedef virEmulatorCapabilities *virEmulatorCapabilitiesPtr;
struct _virEmulatorCapabilities {
<some values here>
};
which will live in src/conf/capabilities.*. Can you shed a light on the
structure internals and where it should be created? IIUC, it'll be
created in the virConnectGetEmulatorCapabilties(), then formated and
immediately disposed.
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list