On Wed, Jan 11, 2012 at 10:02:51AM -0600, Anthony Liguori wrote: > 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 Not sure what you mean. Using VQ is DMA which is pretty common for PCI. > > _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
