On Tue, 03 Sep 2013 13:27:58 +0930
Rusty Russell <> wrote:
> Cornelia Huck <> writes:
> > On Mon, 02 Sep 2013 10:56:20 +0930
> > Rusty Russell <> wrote:
> >
> >> Cornelia Huck <> writes:
> >> > Would it make sense to have a bit 33 "rings big endian" whose validity
> >> > depends on bit 32 set? This would make it possible for ccw to keep its
> >> > current endianness.
> >>
> >> Very awkward. Our experience with bi-endian devices on PowerPC suggests
> >> it's far better to not negotiate endian. It also avoids a branch
> >> everywhere in the driver and host.
> >
> > Ok, so let's skip this feature bit and make virtio-ccw big endian for
> > the ring?
>
> That's one option: it would allow current Linux guests to do a
> compile-time endian switch because we currently assume ARCH=s390 is
> equivalent to "using virtio-ccw only". QEMU may be able to make the
> same assumption.
>
> I worry about future virtio-pci on s390, where this issue will become
> more complicated. "LE everywhere" is a simple rule.
I don't see how virtio-pci could be made to work with the s390 pci
implementation, so I don't think we will see anything but virtio-ccw on
s390 machines.
>
> We still have the question of the endian of per-device headers
> (eg. virtio-blk header) and per-device config space. I'm assuming we'll
> use the same endian as for the ring.
Config "space" for virtio-ccw is not accessed through memory writes but
through special channel commands. Whether it is big or little endian is
completely orthogonal to the endianness of the ring etc. - both would
be fine.
Cornelia
