[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


> Thanks
> Annie

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.