On Fri, 2019-02-08 at 17:11 -0500, Cole Robinson wrote: [...] > +++ b/docs/formatdomain.html.in > @@ -2922,6 +2922,17 @@ > <span class="since">Since 0.1.4</span> > </p> > </dd> > + <dt><code>model</code></dt> > + <dd> > + Indicates the emulated device model of the disk. Typically > + this is indicated solely by the <code>bus</code> property but > + for <code>bus</code> "virtio" the model can be specified further > + with "virtio-transitional", "virtio-non-transitional", or > + "virtio", see
s/, see/. See/ [...] > + <dt><code>virtio-transitional</code></dt> > + <dd>This instructs libvirt to always place the device in a conventional > + PCI slot. The device can work with a virtio 0.9 or virtio 1.0 > + guest driver. > + </dd> I'd reword this a bit to highlight the fact that protocol compatibility is the main point of these devices, and slot assignment stems from it. Something like This device can work both with virtio 0.9 and virtio 1.0 guest drivers, so it's the best choice when compatibility with older guest operating systems is desired. libvirt will plug the device into a conventional PCI slot. > + <dt><code>virtio-non-transitional</code></dt> > + <dd> > + The device can only work with a virtio 1.0 guest driver. In the same vein as the above, This device can only work with virtio 1.0 guest drivers, and it's the recommended option unless compatibility with older guest operating systems is necessary. libvirt will plug the device into either a PCI Express slot or a conventional PCI slot based on the machine type, resulting in a more optimized PCI topology. > + </dd> > + <dt><code>virtio</code></dt> > + <dd> If the device is plugged into a PCIe slot, it acts as a > + virtio-non-transitional device. If plugged into a conventional PCI > slot, > + it will function as a virtio-transitional device. This logic only > + applies to devices that support the transitional models; for other > + devices, <code>virtio</code> behavior will be different. And here too, This device will work like a <code>virtio-non-transitional</code> device when plugged into a PCI Express slot, and like a <code>virtio-transitional</code> device otherwise; libvirt will pick one or the other based on the machine type. This is the best choice when compatibility with libvirt versions older than 5.1.0 is necessary, but it's otherwise not recommended to use it. The idea behind these suggestions is that we should help the user understand the various trade-offs and pick the value that better suits their needs. [...] > +++ b/tests/qemuxml2argvdata/virtio-non-transitional.xml > @@ -0,0 +1,17 @@ > +<domain type='qemu'> > + <name>QEMUGuest1</name> > + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> > + <memory unit='KiB'>219136</memory> > + <os> > + <type arch='x86_64' machine='q35'>hvm</type> > + </os> > + <devices> > + <disk type='block' device='disk' model='virtio-non-transitional'> > + <driver name='qemu' type='raw'/> > + <source dev='/dev/HostVG/QEMUGuest1'/> > + <target dev='vda' bus='virtio'/> > + </disk> > + <controller type='usb' index='0' model='none'/> s/index='0' // [...] > +++ b/tests/qemuxml2argvdata/virtio-transitional.xml > @@ -0,0 +1,17 @@ > +<domain type='qemu'> > + <name>QEMUGuest1</name> > + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> > + <memory unit='KiB'>219136</memory> > + <os> > + <type arch='x86_64' machine='q35'>hvm</type> > + </os> > + <devices> > + <disk type='block' device='disk' model='virtio-transitional'> > + <driver name='qemu' type='raw'/> > + <source dev='/dev/HostVG/QEMUGuest1'/> > + <target dev='vda' bus='virtio'/> > + </disk> > + <controller type='usb' index='0' model='none'/> Here too. Reviewed-by: Andrea Bolognani <abolo...@redhat.com> -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
