On 09.10.2019 20:02, Jonathon Jongsma wrote: > 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@xxxxxxxxxxxxx> >> --- >> 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> >> ... >> <devices> >> - <hostdev mode='subsystem' type='usb'> >> + <hostdev mode='subsystem' type='usb' replug='yes'> >> <source startupPolicy='optional'> >> <vendor id='0x1234'/> >> <product id='0xbeef'/> >> @@ -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? > Yeah, makes sense. Nikolay -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
