Re: Rebooting domu fails in nfs share exported from another domu on the same dom0

[annie li <annie.li@oracle.com>]

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