Re: [libvirt] [PATCH v3 01/12] conf: add replug option for usb hostdev

On Tue, 2019-09-17 at 16:47 +0300, Nikolay Shirokovskiy wrote: > If usb device attached to a domain is unplugged from host and > then plugged back then it will no longer be available in guest. > We are going to support this case so that device will be detached > from qemu on unplug and attached back on replug. As sometimes > this behaviour is not desirable and for backcompat too let's > add 'replug' option for usb hostdev. > > Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy(a)virtuozzo.com&gt; > --- > docs/formatdomain.html.in | 10 ++++- > docs/schemas/domaincommon.rng | 5 +++ > src/conf/domain_conf.c | 30 ++++++++++++++ > src/conf/domain_conf.h | 2 + > tests/qemuxml2argvdata/hostdev-usb-replug.xml | 36 +++++++++++++++++ > .../qemuxml2xmloutdata/hostdev-usb-replug.xml | 40 > +++++++++++++++++++ > tests/qemuxml2xmltest.c | 1 + > 7 files changed, 122 insertions(+), 2 deletions(-) > create mode 100644 tests/qemuxml2argvdata/hostdev-usb-replug.xml > create mode 100644 tests/qemuxml2xmloutdata/hostdev-usb-replug.xml > > diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in > index 86a5261e47..5b0d41760b 100644 > --- a/docs/formatdomain.html.in > +++ b/docs/formatdomain.html.in > @@ -4678,7 +4678,7 @@ > <pre> > ... > &lt;devices&gt; > - &lt;hostdev mode='subsystem' type='usb'&gt; > + &lt;hostdev mode='subsystem' type='usb' replug='yes'&gt; > &lt;source startupPolicy='optional'&gt; > &lt;vendor id='0x1234'/&gt; > &lt;product id='0xbeef'/&gt; > @@ -4777,7 +4777,13 @@ > <dt><code>usb</code></dt> > <dd>USB devices are detached from the host on guest > startup > and reattached after the guest exits or the device is > - hot-unplugged. > + hot-unplugged. If optional <code>replug</code> > + (<span class="since">since 5.8.0</span>) is "yes" then > libvirt > + tracks USB device unplug/plug on host. On unplug the > correspondent "corresponding" is a bit better here > + QEMU device will be be deleted but device stays in > libvirt config. Do we want to mention qemu explicitly here? Presumably this configuration option could be hypervisor indepedendant? Maybe it's better to refer generically to the "guest" or "hypervisor" rather than qemu?