> > > Oh, I see what you meant... in the proper resume case (as opposed to the
> > > cancelled suspend/checkpoint case I was thinking of) there should be no
> > > grant tables in use at this point so most devices should, in theory, be
> > > able to reconnect using v1 grants, any drivers which require v2 grant
> > > tables need to check for them in their resume hook as well as at start
> > > of day.
> > >
> > > Unfortunately frontend devices tear down their grant entries after the
> > > resume rather than before the suspend (I presume this has to do with
> > > faster checkpointing?) which means they could be trying to clear an
> > > entry of the wrong layout, leading the unbounded badness that the
> > > comment refers to.
> > Actually, I think that'd be okay. Drivers should be clearing grant
> > table entries through the gnttab_end_* functions, which always check
> > grant_table_version and do the right thing.
> In the case where you have gone v1->v2 then the entries would have been
> setup while grante_table_version==1 layout but by the time gnttab_end_*
> is called grant_table_version==2 and the wrong thing happens.
Hmm... I still think we're probably okay (in the narrowest possible
sense). Changing grant table version memset()s the shared tables to
zero, which effectively revokes all the grants, so all we need is for
the gnttab_end_*_ref operations to be no-ops when applied to zeroed
grant table slots, and a quick check of the code suggests that they
are.
But, yeah, it's not something we want to be doing anyway, whether it's
safe or not.
> > > I think the choices are basically:
> > > * Always latch to either v1 or v2 at start of day, if we can't get
> > > the version we want then panic (this is a stronger restriction
> > > than the current code which will try to upgrade to v2 on resume)
> > Yeah, that probably counts as a bug in the current code. If we boot
> > on a Xen which only supports v1 tabled then we should probably stick
> > with v1 until we shut down.
> >
> > panic()ing when v2 isn't available sounds like overkill, though.
> It's only if you've already used v2 in this guest.
Ah, okay.
> > Would something like this work?
>
> I don't think so, because I don't think changing the grant table layout
> is safe.
>
> I'm experimenting with this:
>
> Subject: xen: latch grant-table layout at start of day.
>
> It is not possible to switch grant table layout over a save restore
> since entries setup before with the old layout cannot be torn down under
> the new layout.
>
> Also add a grant_table.version parameter to allow the user to force a
> particular layout (e.g. if they know they need to migrate to v1 only
> hosts)
>
> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
Acked-by: Steven Smith <sos22@xxxxxxxxx>
Steven.
signature.asc
Description: Digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home