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

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

On Tue, 20 Aug 2013 10:47:37 +0200
Paolo Bonzini <pbonzini@redhat.com> wrote:

> Il 20/08/2013 10:39, Michael S. Tsirkin ha scritto:
> > On Tue, Aug 20, 2013 at 02:04:10PM +0930, Rusty Russell 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".
> > 
> > Again, this would be a "negative feature", won't it?
> 
> Yes, unless the device model implements both pre-standard and
> post-standard layouts.
> 
> Perhaps we can reserve the high 16 bits of the device ID for the
> standard revision?  Thus pre-standard layout would have device IDs like
> 0x0000xxxx (as it is now).  Post-standard layout would be 0x0001xxxx.

This device ID (in this format) is PCI-specific, isn't it?