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

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

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.
> 
> The discussion was more in the context of a method for backwards
> compatiblity.  If we're changing the PCI layout, that itself is
> sufficient to trigger LE-only mode.
>
> MMIO is already defined as LE-only.

Sorry, are we talking about only config layout
for now, or ring and headers in guest memory as well?

The later is native for MMIO, isn't it?

> CCW is currently native, ie. big
> endian, since it's S/390.
> 
> Anthony originally suggested two feature bits: a big endian and a little
> endian bit.  A device which acks neither needs a heuristic.  This is
> probably overkill given only CCW will have this problem.
>
> > Thus what I'd like to suggest is a new field reporting to
> > guest whether device supports native format, little endian format,
> > or both.
> >
> > This new field will naturally be only exposed in the new layout.
> 
> I really don't want to support both endians; I'd rather have the current
> endian hacks left for legacy virtio, where they're needed anyway.  I
> don't think legacy is worth fixing, either.
> 
> Cheers,
> Rusty.