Anthony Liguori <aliguori@xxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
