Re: [RFC 7/11] virtio_pci: new, capability-aware driver.
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On 01/11/2012 09:45 AM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2012 at 09:28:27AM -0600, Anthony Liguori wrote:On 01/11/2012 09:21 AM, Michael S. Tsirkin wrote:On Wed, Jan 11, 2012 at 09:15:49AM -0600, Anthony Liguori wrote:This is similar to what we have now. But it's still buggy: e.g. if guest updates MAC byte by byte, we have no way to know when it's done doing so.This is no different than a normal network card. You have to use a secondary register to trigger an update. Regards, Anthony LiguoriPossible but doesn't let us layer nicely to allow unchanged drivers that work with all transports (new pci, old pci, non pci).If we declare config space LE, then we have to touch all drivers. There's no way around it because the virtio API is byte-based, not word based.Fine but don't we want to be compatible with old hypervisors?
We can modify the drivers to work either with a virtio1 or virtio2 transport. If the only difference is that we move to word access instead of byte access for the config space, it's a nop because drivers don't rely on sub-word access today.
This is why I'm suggesting making the virtio API (and then the virtio-pci ABI) word based. It gives us the flexibility to make endianness a property of the transport and not a property of the devices. Regards, Anthony LiguoriSome fields are 64 bit, this is still tricky to do atomically. What's the objection to using a config VQ?
Then we move very far away from something that looks like a PCI device. The problem we're having here is specifically where we've deviated from what a normal PCI device would do. Fixing that by deviating even further seems counter intuitive to me.
Regards, Anthony Liguori
_______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization