Re: [PATCHv2 RFC] virtio-spec: flexible configuration layout

Michael S. Tsirkin
2011-11-14T06:58:37Z

On Sun, Nov 13, 2011 at 05:14:27PM +0200, Michael S. Tsirkin wrote:
> On Fri, Nov 11, 2011 at 02:54:31PM +1030, Rusty Russell wrote:
> > On Wed, 09 Nov 2011 22:57:28 +0200, Sasha Levin <levinsasha928@gmail.com> wrote:
> > > On Wed, 2011-11-09 at 22:52 +0200, Michael S. Tsirkin wrote:
> > > > On Wed, Nov 09, 2011 at 10:24:47PM +0200, Sasha Levin wrote:
> > > > > It'll be a bit harder deprecating it in the future.
> > > >
> > > > Harder than ... what ?
> > >
> > > Harder than allowing devices not to present it at all if new layout
> > > config is used. Right now the simple implementation is to use MMIO for
> > > config and device specific, and let it fallback to legacy for ISR and
> > > notifications (and therefore, this is probably how everybody will
> > > implement it), which means that when you do want to deprecate legacy,
> > > there will be extra work to be done then, instead of doing it now.
> >
> > Indeed, I'd like to see two changes to your proposal:
> >
> > (1) It should be all or nothing. If a driver can find the virtio header
> > capability, it should only use the capabilties. Otherwise, it
> > should fall back to legacy.
>
> Okay, but going forward, if we add more capabilities, we probably won't
> want to require them and fail to load if not there. That's really why I
> wanted to make the failover ignore any capability separately - to make
> this future proof. I'm not terribly fixated on this, it just seemed a
> bit more symmetrical to treat all capabilities in the same way. Hmm?
>
> > Your draft suggests a mix is possible;
> > I prefer a clean failure (ie. one day don't present a BAR 0 *at
> > all*, so ancient drivers just fail to load.).
>
> Just to clarify, as written in draft this is possible with the current
> spec proposal. So I'm guessing there's some other motivation that you
> had in mind?
>
> > (2) There's no huge win in keeping the same layout. Let's make some
> > cleanups.
>
> About this last point - what cleanups do you have in mind? Just move
> some registers around? I guess we could put feature bits near each
> other, and move device status towards the end to avoid wasting 3 bytes.
> The win seems minimal, but the change does make legacy hypervisor
> support in guests more cumbersome, as we need to spread coditional code
> around instead of localizing it in the initialization path.
>
> > There are more users ahead of us then behind us (I
> > hope!).
>
> In that case isn't it safe to assume we'll find some uses
> for the reserved registers?
>
> > But I think this is the right direction!
> >
> > Thanks,
> > Rusty.

Note: waiting on response to the above before I tweak the
spec again.

--
MST