[libvirt] [PATCH 0/6] RFC: qemu: virtio-{non-}transitional support

Andrea Bolognani abologna at redhat.com
Tue Jan 15 13:30:14 UTC 2019


On Sun, 2019-01-13 at 18:12 -0500, Cole Robinson wrote:
[...]
> The main RFC bits here are:
> 
> * The disk approach. danpb and I briefly discussed on IRC adding
>   new bus= values vs a new model= attribute. We decided model=
>   is the lesser of two evils, since bus= handling in apps is
>   tied with target= generation, so adding new virtio-X bus=
>   values will cause more work for apps. These patches add
>   a <disk model=X/> attribute

This sounds fairly reasonable, but I reserve the right to change my
mind after looking at the code and thinking about it a bit more :)

> * The XML and naming. Previous discussions seemed to favor adding
>   new model-style values rather than a 'transitional' attribute
>   or similar. So these patches add model='virtio-transitional'
>   and model='virtio-non-transitional'

Yeah, that's what I recall the consensus being.

> * The PCI address handling. I just mapped virtio-non-transitional
>   to imply plain PCI addressing. I think that's all we need but
>   I'm not positive so I'd appreciate a review of that approach.

I don't think that's right. Let me fish up a message I wrote a while
ago summing up interactions between VirtIO devices and PCI (Express)
slots:

  http://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg03133.html

Basically VirtIO 0.9 requires IO space to be available, and 1.0 did
away with that requirement because PCI Express, unlike conventional
PCI, allows devices *not* to have IO space.

So transitional devices, which must work with both 0.9 and 1.0, can
depend on IO space being available and as such will only work when
plugged into conventional PCI slots, whereas non-transitional
devices don't need IO space and can thus be plugged into either
conventional PCI and PCI Express slots.

Ultimately, then, transitional (rather than non-transitional)
devices are the ones that must be forced into conventional PCI
slots.

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list