OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

"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.  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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]