On 04/23/2013 10:45 AM, Laine Stump wrote: > A domain's <interface> or <hostdev>, as well as a <network>'s > <forward>, can now have an optional <driver name='kvm|vfio'/> > element. As of this patch, there is no functionality behind this new > knob - this patch adds support to the domain and network > formatter/parser, and to the RNG and documentation. > > When then backend is added, legacy KVM PCI device assignment will s/then/the/ > continue to be used when no driver name is specified (or if <driver > name='kvm'/> is specified), but if driver name is 'vfio', the new UEFI > Secure Boot compatible VFIO device assignment will be used. > > Note that the parser doesn't automatically insert the current default > value of this setting. This is done on purpose because the two > possibilities are functionally equivalent from the guest's point of > view, and we want to be able to automatically start using vfio as the > default (even for existing domains) at some time in the future. This > is similar to what was done with the "vhost" driver option in > <interface>. Yes, leaving an unspecified element as hypervisor default has worked for us in the past, especially when the choice of host driver should not be guest-visible. > --- > docs/formatdomain.html.in | 42 ++++++++++++++++++++++- > docs/formatnetwork.html.in | 15 ++++++++ > docs/schemas/domaincommon.rng | 79 ++++++++++++++++++++++++++++--------------- > docs/schemas/network.rng | 11 ++++++ > src/conf/domain_conf.c | 36 ++++++++++++++++++++ > src/conf/domain_conf.h | 11 ++++++ > 6 files changed, 166 insertions(+), 28 deletions(-) > > diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in > index 888c005..0e5b00c 100644 > --- a/docs/formatdomain.html.in > +++ b/docs/formatdomain.html.in > @@ -2340,7 +2340,22 @@ > the device as can be found with the <code>lspci</code> or > with <code>virsh > nodedev-list</code>. <a href="#elementsAddress">See above</a> for > - more details on the address element. > + more details on the address element.</dd> > + <dt><code>driver</code></dt> > + <dd> > + PCI devices can have an optional <code>driver</code> > + subelement that specifies which backend driver to use for PCI > + device assignment. Use the <code>name</code> attribute to > + select either "vfio" (for the new VFIO device assignment > + backend, which is compatible with UEFI SecureBoot) or "kvm" > + (for the legacy device assignment handled directly by the KVM > + kernel module)<span class="since">Since 1.0.5 (QEMU and KVM > + only, requires kernel 3.6 or newer)</span>. Currently, "kvm" > + is the default used by libvirt when not explicitly provided, > + but since the two are functionally equivalent, this default > + could be changed in the future with no impact to domains that > + don't specify anything. IIRC, we have talked about managing host devices across all hypervisors, since it is a shared host resource. If that's true, then what happens if LXC wants to start using a driver? Or should LXC only use vfio and never use kvm? Also, didn't you say that xen used yet another driver, in which case we should consider listing that in the RNG. > + device assignment performed directly by the kvm kernel module > + (the default is currently "kvm", but is subject to change). > + <span class="since">Since 1.0.5 (QEMU and KVM only, requires kernel 3.6 or newer)</span> Long line (several times). > +++ b/docs/schemas/domaincommon.rng > @@ -1923,28 +1923,40 @@ > </optional> > <optional> > <element name="driver"> > - <optional> > - <attribute name="name"> > - <choice> > - <value>qemu</value> > - <value>vhost</value> > - </choice> > - </attribute> > - </optional> > - <optional> > - <attribute name="txmode"> > - <choice> > - <value>iothread</value> > - <value>timer</value> > - </choice> > - </attribute> > - </optional> > - <optional> > - <ref name="ioeventfd"/> > - </optional> > - <optional> > - <ref name="event_idx"/> > - </optional> > + <choice> > + <group> > + <attribute name="name"> > + <choice> > + <value>kvm</value> > + <value>vfio</value> > + </choice> > + </attribute> > + </group> > + <group> > + <optional> > + <attribute name="name"> > + <choice> > + <value>qemu</value> > + <value>vhost</value> So for define='interface-options', we are extending the exiting <driver> so that there are now four values for <driver name=.../>, but only the two older options allow other attributes. Can the two ever overlap, or are we safe in that kvm/vfio are for hostdev interface passthrough, while qemu/vhost is for emulation, so the two types of driver choices never make sense at once? > + </choice> > + </attribute> > + </optional> > + <optional> > + <attribute name="txmode"> > + <choice> > + <value>iothread</value> > + <value>timer</value> > + </choice> > + </attribute> > + </optional> > + <optional> > + <ref name="ioeventfd"/> > + </optional> > + <optional> > + <ref name="event_idx"/> > + </optional> > + </group> > + </choice> > <empty/> > </element> > </optional> > @@ -3084,14 +3096,27 @@ > <attribute name="type"> > <value>pci</value> > </attribute> > - <element name="source"> > + <interleave> > <optional> > - <ref name="startupPolicy"/> > + <element name="driver"> > + <attribute name="name"> > + <choice> > + <value>kvm</value> > + <value>vfio</value> > + </choice> > + </attribute> > + <empty/> Whereas for define='hostdevsubsyspci', we are completely adding a new subelement, with only two choices for the new attribute. > + </element> > </optional> > - <element name="address"> > - <ref name="pciaddress"/> > + <element name="source"> > + <optional> > + <ref name="startupPolicy"/> > + </optional> > + <element name="address"> > + <ref name="pciaddress"/> > + </element> > </element> > - </element> > + </interleave> > </define> > > <define name="hostdevsubsysusb"> > diff --git a/docs/schemas/network.rng b/docs/schemas/network.rng > index 6c3fae2..493edae 100644 > --- a/docs/schemas/network.rng > +++ b/docs/schemas/network.rng > @@ -149,6 +149,17 @@ > </attribute> > </element> > </optional> > + <optional> > + <element name="driver"> > + <attribute name="name"> > + <choice> > + <value>kvm</value> > + <value>vfio</value> > + </choice> > + </attribute> > + <empty/> > + </element> > + </optional> > </interleave> Looks okay to me. I'm not sure if we are ready to push this without more patches in the series, but at least I think the XML is on the right track. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list