Linux Virtualization - Jun 2013 - [PATCH RFC] virtio-pci: new config layout: using memory BAR

Anthony Liguori <aliguori at us.ibm.com> writes:
> 4) Do virtio-pcie, make it PCI-e friendly (drop the IO BAR completely),
give
>    it a new device/vendor ID.   Continue to use virtio-pci for existing
>    devices potentially adding virtio-{net,blk,...}-pcie variants for
>    people that care to use them.
Now you have a different compatibility problem; how do you know the
guest supports the new virtio-pcie net?

If you put a virtio-pci card behind a PCI-e bridge today, it's not
compliant, but AFAICT it will Just Work.  (Modulo the 16-dev limit).

I've been assuming we'd avoid a "flag day" change; that
devices would
look like existing virtio-pci with capabilities indicating the new
config layout.
> I think 4 is the best path forward.  It's better for users (guests
> continue to work as they always have).  There's less confusion about
> enabling PCI-e support--you must ask for the virtio-pcie variant and you
> must have a virtio-pcie driver.  It's easy to explain.
Removing both forward and backward compatibility is easy to explain, but
I think it'll be harder to deploy.  This is your area though, so perhaps
I'm wrong.
> It also maps to what regular hardware does.  I highly doubt that there
> are any real PCI cards that made the shift from PCI to PCI-e without
> bumping at least a revision ID.
Noone expected the new cards to Just Work with old OSes: a new machine
meant a new OS and new drivers.  Hardware vendors like that.

Since virtualization often involves legacy, our priorities might be
different.

Cheers,
Rusty.

Hi Rusty,

Rusty Russell <rusty at rustcorp.com.au> writes:
> Anthony Liguori <aliguori at us.ibm.com> writes:
>> 4) Do virtio-pcie, make it PCI-e friendly (drop the IO BAR completely),
give
>>    it a new device/vendor ID.   Continue to use virtio-pci for existing
>>    devices potentially adding virtio-{net,blk,...}-pcie variants for
>>    people that care to use them.
>
> Now you have a different compatibility problem; how do you know the
> guest supports the new virtio-pcie net?
We don't care.

We would still use virtio-pci for existing devices.  Only new devices
would use virtio-pcie.
> If you put a virtio-pci card behind a PCI-e bridge today, it's not
> compliant, but AFAICT it will Just Work.  (Modulo the 16-dev limit).
I believe you can put it in legacy mode and then there isn't the 16-dev
limit.  I believe the only advantage of putting it in native mode is
that then you can do native hotplug (as opposed to ACPI hotplug).

So sticking with virtio-pci seems reasonable to me.
> I've been assuming we'd avoid a "flag day" change; that
devices would
> look like existing virtio-pci with capabilities indicating the new
> config layout.
I don't think that's feasible.  Maybe 5 or 10 years from now, we switch
the default adapter to virtio-pcie.
>> I think 4 is the best path forward.  It's better for users (guests
>> continue to work as they always have).  There's less confusion
about
>> enabling PCI-e support--you must ask for the virtio-pcie variant and
you
>> must have a virtio-pcie driver.  It's easy to explain.
>
> Removing both forward and backward compatibility is easy to explain, but
> I think it'll be harder to deploy.  This is your area though, so
perhaps
> I'm wrong.
My concern is that it's not real backwards compatibility.
>> It also maps to what regular hardware does.  I highly doubt that there
>> are any real PCI cards that made the shift from PCI to PCI-e without
>> bumping at least a revision ID.
>
> Noone expected the new cards to Just Work with old OSes: a new machine
> meant a new OS and new drivers.  Hardware vendors like that.
Yup.
> Since virtualization often involves legacy, our priorities might be
> different.
So realistically, I think if we introduce virtio-pcie with a different
vendor ID, it will be adopted fairly quickly.  The drivers will show up
in distros quickly and get backported.

New devices can be limited to supporting virtio-pcie and we'll certainly
provide a way to use old devices with virtio-pcie too.  But for
practical reasons, I think we have to continue using virtio-pci by
default.

Regards,

Anthony Liguori
>
> Cheers,
> Rusty.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Anthony Liguori <aliguori at us.ibm.com> writes:
> Hi Rusty,
>
> Rusty Russell <rusty at rustcorp.com.au> writes:
>
>> Anthony Liguori <aliguori at us.ibm.com> writes:
>>> 4) Do virtio-pcie, make it PCI-e friendly (drop the IO BAR
completely), give
>>>    it a new device/vendor ID.   Continue to use virtio-pci for
existing
>>>    devices potentially adding virtio-{net,blk,...}-pcie variants
for
>>>    people that care to use them.
>>
>> Now you have a different compatibility problem; how do you know the
>> guest supports the new virtio-pcie net?
>
> We don't care.
>
> We would still use virtio-pci for existing devices.  Only new devices
> would use virtio-pcie.
My concern is that new features make the virtio-pcie driver so desirable
that libvirt is pressured to use it ASAP.  Have we just punted the
problem upstream?

(Of course, feature bits were supposed to avoid such a transition issue,
but mistakes accumulate).

Cheers,
Rusty.

On 6 June 2013 15:59, Anthony Liguori <aliguori at us.ibm.com>
wrote:
> We would still use virtio-pci for existing devices.  Only new devices
> would use virtio-pcie.
Surely you'd want to support both for any new device, because
(a) transport is orthogonal to backend functionality
(b) not all existing machine models have pci-e ?

Or am I misunderstanding?

thanks
-- PMM