[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] virtio and endian-ness
On Tue, Aug 20, 2013 at 09:03:59AM +0200, Cornelia Huck wrote: > On Tue, 20 Aug 2013 14:04:10 +0930 > Rusty Russell <rusty@au1.ibm.com> wrote: > > > Cornelia Huck <cornelia.huck@de.ibm.com> writes: > > > On Mon, 19 Aug 2013 12:27:53 +0300 > > > "Michael S. Tsirkin" <mst@redhat.com> wrote: > > > > > >> On Mon, Aug 19, 2013 at 11:09:44AM +0200, Cornelia Huck wrote: > > >> > On Mon, 19 Aug 2013 12:08:35 +0300 > > >> > "Michael S. Tsirkin" <mst@redhat.com> wrote: > > >> > > > >> > > On Mon, Aug 19, 2013 at 05:17:30PM +0930, Rusty Russell wrote: > > >> > > > "Michael S. Tsirkin" <mst@redhat.com> writes: > > >> > > > > 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. > > > > > > Just as point of data: For virtio-ccw we should be able to easily > > > extend feature bits. > > > > Yes, I think virtio-ccw and virtio-mmio could simply add a new feature > > bit to say "1.0 compliant". In 20 years time that might look a > > bit awkward, but that's probably OK unless there's an obvious > > out-of-band mechanism to use. > > A feature bit would probably be easier for virtio-ccw - at least, > there's a lot less to architecture on our side (no need for new channel > commands etc.) Do you have a revision field somewhere, in case host wants to disable old drivers? > > > > BTW "standards compliant" for proposals so far means: > > 1) config fields are LE. > > 2) device-specfic headers are LE (eg. virtio_net_hdr). > > 3) fields in the ring are LE. > > > > For virtio-ccw, the actual commands to manipulate the virtio devices and > > bus (ie. struct ccw1) would remain BE, because that's the nature of CCW. > > As they are just a means to do I/O as dictated by the hardware > architecture, anything else would be weird. > > > > > > Regarding little-endian rings, we could probably hack up some code to > > > measure the overhead that would give us. > > > > That would be great! > > I'll follow up on this when we have some results.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]