On 06/20/14 16:19, Michal Privoznik wrote: > The virEmulatorCapabilities is going to hold emulator capabilities, > surprisingly. It's intended to be able to cover qemuCaps, lxcCaps > (once we invent them, if ever) and so on. Among with adding the code > itself, both some documentation and basic testing is introduced too. > > Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> > --- ... > > diff --git a/docs/formatemulatorcaps.html.in b/docs/formatemulatorcaps.html.in > new file mode 100644 > index 0000000..beea1a9 > --- /dev/null > +++ b/docs/formatemulatorcaps.html.in > @@ -0,0 +1,52 @@ > +<?xml version="1.0" encoding="UTF-8"?> > +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> > +<html xmlns="http://www.w3.org/1999/xhtml";> > + <body> > + <h1>Emulator capabilities XML format</h1> > + > + <ul id="toc"></ul> > + > + <h2><a name="Motivation">Motivation</a></h2> > + > + <p>Sometimes, when a new domain is to be created it may come handy to know > + the capabilities of the hypervisor so the correct combination of devices and > + drivers is used. For example, when management application is considering the > + mode for a host device's passthrough there are several options depending not > + only on host, but on hypervisor in question too. If the hypervisor is qemu > + then it needs to be more recent to support VFIO, while legacy KVM is > + achievable just fine with older one.</p> > + > + <p>The main difference between <a > + href="formatcaps.html">virConnectGetCapabilities</a> and the emulator > + capabilities API is, the former one aims more on the host capabilities (e.g. > + NUMA topology, security models in effect, etc.) while the latter one > + specializes on the hypervisor capabilities.</p> > + > + <h2><a name="elements">Element and attribute overview</a></h2> > + > + <p>The root element that emulator capability XML document starts with has > + name <code>emulatorCapabilities</code>. It contains at least three direct > + child elements:</p> We also have a <features> subelement of <guest> in the <capabilities> XML which is used for a similar thing although it doesn't support a per-machine-type output, only per-binary capabilities. Should we add this more granular approach and abandon the old one? Peter > + > +<pre> > +<emulatorCapabilities> > + <path>/usr/bin/qemu-system-x86_64</path> > + <domain>kvm</domain> > + <machine>pc-i440fx-2.1</machine> > + ... > +</emulatorCapabilities> > +</pre> > + <dl> > + <dt>path</dt> > + <dd>The full path to the emulator binary.</dd> > + > + <dt>domain</dt> > + <dd>Describes the <a href="formatdomain.html#elements">virtualization > + type</a> (or so called domain type).</dd> > + > + <dt>machine</dt> > + <dd>The domain's <a href="formatdomain.html#elementsOSBIOS">machine > + type</a>.</dd> > + </dl> > + </body> > +</html>
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list