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


Help: OASIS Mailing Lists Help | MarkMail Help

virtio message

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

Subject: Re: [virtio] Re: [virtio-comment] [PATCH RFC] virtio-pci: new configuration layout

Cornelia Huck <cornelia.huck@de.ibm.com> writes:
> On Mon, 02 Sep 2013 10:56:20 +0930
> Rusty Russell <rusty@au1.ibm.com> wrote:
>> Cornelia Huck <cornelia.huck@de.ibm.com> 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.

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.

>> Legacy devices will not be spec compliant, though we will map out the
>> differences for implementors and to make sure that transitional devices
>> & drivers are still possible.  This legacy part will eventually be a
>> separate document.
>> I expect them legacy to be firmly deprecated within a few years: new
>> features will probably only be offered for standard devices, and for PCI
>> there are some nice proposals in the standard which make life easier,
>> eg. for bootloaders.
> Is there any reason the legacy version can't stay in, with a big fat
> warning "new devices are not supposed to implement this"?

In the long term, a simpler spec will increase adoption.  That's why I
proposed a separate document.  That looks better than a document studded
with examples of our previous mistakes :)

> Another thing we need to keep in mind is that switching a device driver
> to support a new version of a device is not the way it works on every
> system. On s390, there's generally no device driver as such - Linux is
> the oddball there.

Yes, this makes the transition more difficult.  But I believe we are
still at the stage where there are more implementations ahead of us then
exist now, so my preference is for immediate pain and long-term gain.


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