xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: annie li <annie.li@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: Rebooting domu fails in nfs share exported from another domu on the same dom0
Date: Mon, 21 Jul 2014 11:02:54 -0400	[thread overview]
Message-ID: <53CD2B9E.60706@oracle.com> (raw)
In-Reply-To: <20140721100227.GA1040@zion.uk.xensource.com>


On 2014/7/21 6:02, Wei Liu wrote:
> On Fri, Jul 18, 2014 at 05:43:23PM -0400, annie li wrote:
> [...]
>>>> When doing grantcopy for netback, xen requires the source is dom0. However,
>>>> it is vm2 in this case.
>>> Would it be possible in the hypervisor to have an extra check where you
>>> look to see if the source (dom0 in this case) has this page mapped
>> >from another guest? As in, this is a bit of A->B->C transition
>>> and we want to do A->C (B is dom0). If you figure out that the PFN
>>> belongs to A and you are doing a copy of A's page to C's page from B (dom0)
>>> page (and B PFN is actually mapped to be A's page), then why
>>> not just copy from A to C directly?
>>>
>>> Hmm. Linux kernel could actually also have this information (it does
>>> already I think) and we could search for that if the grant copy fails
>>> and if so alter the source and retry the grant copy. Instead of dom0
>>> 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.

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 .

Thanks
Annie

  reply	other threads:[~2014-07-21 15:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-16 20:36 Rebooting domu fails in nfs share exported from another domu on the same dom0 annie li
2014-07-17 15:49 ` Roger Pau Monné
2014-07-17 16:56   ` annie li
2014-07-18 18:53     ` Konrad Rzeszutek Wilk
2014-07-18 19:31       ` annie li
2014-07-18 19:43         ` Konrad Rzeszutek Wilk
2014-07-18 20:17           ` annie li
2014-07-18 20:22             ` Konrad Rzeszutek Wilk
2014-07-18 20:31               ` annie li
2014-07-18 21:07                 ` Konrad Rzeszutek Wilk
2014-07-18 21:43                   ` annie li
2014-07-21 10:02                     ` Wei Liu
2014-07-21 15:02                       ` annie li [this message]
2014-07-21 23:05                         ` Wei Liu
2014-07-23  1:58                           ` annie li
2014-07-28 14:14 ` David Vrabel
2014-07-28 16:14   ` annie li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53CD2B9E.60706@oracle.com \
    --to=annie.li@oracle.com \
    --cc=roger.pau@citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).