Re: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

On Tue, Mar 27, 2007 at 02:02:39AM +0100, Keir Fraser wrote:
> On 27/3/07 01:52, "Herbert Xu" <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
> 
> > It sounds good but looking further there is still an issue.
> > 
> > The problem is that the gpfn itself is not sufficient if we want to
> > release the grant table entry.  We need to have the grant handle too
> > in order to free the entry completely.  If we did provide the handle
> > then this will just be the same operation that I was trying to add
> > except that now we're adding it under XENMEM_add_to_physmap :)
> 
> Well, it could be a bit more work to change, but what does a p2m entry look
> like for a grant mapping? The p2m table should be a very convenient place to
> have typed entries, with one of those types being grant-mapping, and
> including the maptrack handle. The MFN can be derived from the maptrack
> handle where that is required. This would then conveniently be enough
> information to perform implicit unmaps (the lack of support of which is an
> annoying limitation for non-auto-translate guests which it would be really
> nice to avoid for auto-translate guests, particularly since it ought to be
> not really all that hard afaics).

The ia64 p2m entry is 64bit and some bits are already used
so that there is no room for storing grant table related handle.
I don't think storing the maptrack handle instead of MFN is good idea
because it would make the p2m more complicated.

Is it possible to look up grant table reference by MFN effectively?
Probably MFN-keyed hash table whose entry is struct active_grant_table.
I'm not sure whether it is effective compared to guest providing
grant refernece, though.


> This is pretty much the avenue (hopefully not a dead end!) that I pushed
> Isaku Yamahata down when he queried physmap semantics a week or so ago.
> Sadly we've had no need for grant mappings in x86 auto-translate guests yet,
> so there's no example x86 implementation to lead the way. :-)

The ia64 p2m semantic is now fixed in xen-ia64-unstable.hg so that
page_is_removable() arch hook can be removed.
I'll send the patch to remove the hook after the next pull.

-- 
yamahata

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel