Re: [RFC 7/11] virtio_pci: new, capability-aware driver.

[Anthony Liguori <anthony@xxxxxxxxxxxxx>]

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