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

["Michael S. Tsirkin" <mst@redhat.com>]

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?

-- 
MST