On 01/11/2012 09:45 AM, Michael S. Tsirkin wrote:

On Wed, Jan 11, 2012 at 09:28:27AM -0600, Anthony Liguori wrote:

quoted

On 01/11/2012 09:21 AM, Michael S. Tsirkin wrote:

quoted

On Wed, Jan 11, 2012 at 09:15:49AM -0600, Anthony Liguori wrote:

quoted

quoted

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 Liguori

Possible 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.

quoted

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 Liguori

Some 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