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

[Cornelia Huck <cornelia.huck@de.ibm.com>]

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.

> > > > >> 
> > > > >> 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.
> > > > >
> > > > > Sorry, are we talking about only config layout
> > > > > for now, or ring and headers in guest memory as well?
> > > > >
> > > > > The later is native for MMIO, isn't it?
> > > > 
> > > > Sorry, you're right.
> > > > 
> > > > I was talking about everything, though they're potentially separate
> > > > decisions.
> > > > 
> > > > Cheers,
> > > > Rusty.
> > > 
> > > So, I'll focus on the config space for now.
> > > That's also mostly a PCI thing and clearly off datapath so we are safe
> > > from that POV (I think you mentioned some concerns on the last call).
> > > 
> > > Though we'll need to think about CCW.
> > > It could be benefitial to involve some folks who work on this:
> > > I think cornelia.huck@de.ibm.com and fred.konrad@greensocs.com
> > > were involved in the past.
> > 
> > I'm already here, just haven't time to respond yet :)
> 
> Great.
> To put it shortly, what we were discussing for PCI
> is using a separate set of addresses for the
> virtio config, with a slightly different layout for
> the common registers, and with device specific config also
> being little endian.
> 
> PCI has a 256 "config space" channel that we intend to
> use to supply information such as availability of
> the new layout and the addresses to use for
> common and device specific registers.
> 
> I'll work on a spec patch for that, so
> if above is not very clear, just wait until
> I send that to list.

OK. I'll hope I can understand that, given my limited knowledge of pci.

> 
> What kind of mechanism would be appropriate for
> virtio CCW?

One idea might be that all devices start out in 'legacy mode' and we
add either a feature bit or a new channel command that switches to
'standard mode'. Old hosts would reject that command, while old guests
would simply not issue it.

Another idea is to look at the read_conf/write_conf channel commands
and introduce a new pair of read_conf_le/write_conf_le commands. Again,
compatibility would be achived via the host doing command rejects.

We also have the possibility to convey extra information about the
control unit (the device) in the 'extended sense id data' via the sense
id command. Basically, we can encode some supported channel commands in
there, but we would need a new command type for that architectured.
We'd still need to rely on the command rejects mentioned above, though.

Regarding little-endian rings, we could probably hack up some code to
measure the overhead that would give us.