[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 <firstname.lastname@example.org> writes: > On Mon, 02 Sep 2013 10:56:20 +0930 > Rusty Russell <email@example.com> wrote: > >> Cornelia Huck <firstname.lastname@example.org> 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. Cheers, Rusty.