Re: [Xen-devel] Rebooting domu fails in nfs share exported from another domu on the same dom0

[annie li <annie.li@xxxxxxxxxx>]

On 2014/7/21 19:05, Wei Liu wrote:
> On Mon, Jul 21, 2014 at 11:02:54AM -0400, annie li wrote:
> [...]
> > > > > being the source it is the C guest (vm2)? Thought I don't know if
> > > > > the hypercall allows us to make a grant_copy on behalf of two
> > > > > other guests.
> > > > Oh... I remember netback did have some grant_copy code on behalf of two
> > > > guests on same server, and it was removed later on. So I think grantcopy
> > > > A->C works for this case with the precondition that we can recognize this
> > > > page is mapped from another guest.
> > > I have not followed this thread closely.
> > >
> > > The tracking facility was removed because it was dead at that time. See
> > > 43e9d19 ("xen-netback: remove page tracking facility").
> > >
> > > However I think the latest netback with mapping scheme does have
> > > something similar. I can see there's a "foreign_queue" check in
> > > xenvif_gop_frag_copy. Is that not enough?
> > Correct, this mapping scheme does similar thing, but it is for communication
> > between two vifs on the same server, the original page is mapped by netback
> > tx path. Here, this issue is caused when the page mapped by blkback.
> I see.
>
> > What I am thinking is:  checking whether the page is mapped, if yes, then
> > does grant copy from source to dest directly instead of Dom0->dest since a
> > condition check fails in mm.c if the original page is from another vm for
> > situation Dom0->dist .
> The foreign frame is marked with FOREIGN_FRAME_BIT in p2m code so you
> can probably make use of that? However gref is not embedded in struct
> page.
Yes, no gref.
Let me look at xen grant table code to see whether there is a way to get 
gref for specific page.
Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel