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 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.
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
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
