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


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

What kind of mechanism would be appropriate for
virtio CCW?


Actually, virtio-mmio would also be affected:
while I understand that it made config space LE
already, it would need a way to report support for
the new common layout.

Peter, could you comment please?

> > 
> > I'm not sure if we need to follow some procedure
> > to invite people to get involved - could you
> > handle that?
> > 


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