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 02:16:11PM +0200, Cornelia Huck wrote:
> 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.

If guest can discover whether host supports the new layout,
why would there be any rejects?


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


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