[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 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

Yes, no gref.
Let me look at xen grant table code to see whether there is a way to get gref for specific page.


Xen-devel mailing list



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