[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 page. Wei. > Thanks > Annie _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |