Re: [virtio-comment] virtio and endian-ness

[Cornelia Huck <cornelia.huck@de.ibm.com>]

On Tue, 20 Aug 2013 18:12:05 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Tue, Aug 20, 2013 at 04:52:34PM +0200, Cornelia Huck wrote:
> > On Tue, 20 Aug 2013 17:01:25 +0300
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > 
> > > On Tue, Aug 20, 2013 at 09:03:59AM +0200, Cornelia Huck wrote:
> > > > On Tue, 20 Aug 2013 14:04:10 +0930
> > > > Rusty Russell <rusty@au1.ibm.com> wrote:
> > > > 
> > > > > Cornelia Huck <cornelia.huck@de.ibm.com> writes:
> > > > > > On Mon, 19 Aug 2013 12:27:53 +0300
> > > > > > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > > > >
> > > > > >> On Mon, Aug 19, 2013 at 11:09:44AM +0200, Cornelia Huck wrote:
> > > > > >> > On Mon, 19 Aug 2013 12:08:35 +0300
> > > > > >> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > > > >> > 
> > > > > >> > > On Mon, Aug 19, 2013 at 05:17:30PM +0930, Rusty Russell wrote:
> > > > > >> > > > "Michael S. Tsirkin" <mst@redhat.com> writes:
> > > > > >> > > > > On Mon, Aug 19, 2013 at 12:21:03PM +0930, Rusty Russell wrote:
> > > > > >> > > > >> "Michael S. Tsirkin" <mst@redhat.com> writes:
> > > > > >> > > > >> > During the last TC meeting, we discussed making virtio little endian.
> > > > > >> > > > >> > It was suggested that a feature bit can be used for this,
> > > > > >> > > > >> > but I now think I see two problems:
> > > > > >> > > > >> >
> > > > > >> > > > >> >
> > > > > >> > > > >> > 1. Features are optional,
> > > > > >> > > > >> > in that there's no way for device to communicate to
> > > > > >> > > > >> > guest that guest must ack a feature bit, and e.g. fail
> > > > > >> > > > >> > if guest does not ack.
> > > > > >> > > > >> >
> > > > > >> > > > >> > On the other hand, it seems likely
> > > > > >> > > > >> > that a hardware virtio device might want to *only* implement
> > > > > >> > > > >> > little endian format and not both big and little endian.
> > > > > >> > > > >> >
> > > > > >> > > > >> > In other words this would be something Paolo once called
> > > > > >> > > > >> > a "negative feature".
> > > > > >> > > > >> >
> > > > > >> > > > >> > 2. With virtio-pci we are running out of transport bits,
> > > > > >> > > > >> > and need a new config space layout to add extra feature bits.
> > > > > >
> > > > > > Just as point of data: For virtio-ccw we should be able to easily
> > > > > > extend feature bits.
> > > > > 
> > > > > Yes, I think virtio-ccw and virtio-mmio could simply add a new feature
> > > > > bit to say "1.0 compliant".  In 20 years time that might look a
> > > > > bit awkward, but that's probably OK unless there's an obvious
> > > > > out-of-band mechanism to use.
> > > > 
> > > > A feature bit would probably be easier for virtio-ccw - at least,
> > > > there's a lot less to architecture on our side (no need for new channel
> > > > commands etc.)
> > > 
> > > Do you have a revision field somewhere, in case host wants
> > > to disable old drivers?
> > 
> > No, we don't. If we wanted to reject old drivers, we'd probably need to
> > go with the command reject route.
> 
> OK, I think architecting something like this would be necessary then.
> Can you suggest a clean way that device can currently reject
> an existing driver?
> 

The basic idea would be:
- Pick one (or more) of the existing channel commands and declare them
v1. Have an equivalent new channel command for v2 (possibly with a
different payload that might include version information).
- For a v1 device, handle the existing command as before. The v2
channel command gets unit check with command reject (which will happen
on old hosts automatically, since they do this for any command they
don't know).
- For a v2 device, accept the v2 command. The existing command will get
unit check with command reject (fencing off old drivers).

(I'll need to think about this a bit more.)