xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: annie li <annie.li@oracle.com>
To: roger.pau@citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Rebooting domu fails in nfs share exported from another domu on the same dom0
Date: Wed, 16 Jul 2014 16:36:29 -0400	[thread overview]
Message-ID: <53C6E24D.7050903@oracle.com> (raw)

Hi

I hit a problem in such scenario: vm1 is running and export nfs service, 
dom0 mount this nfs, and vm2 is booted in this nfs location. vm1 and vm2 
are running on the same dom0.

When this bug happens, the data flow is:  vm2 blkfront-> vm2 blkback-> 
loop -> nfs file -> nfs client -> bridge priv1 -> vm1 vif -> vm1 netback 
-> vm1 netfront.

In above data flow, nfs implements direct io, blkfront and blkback uses 
grantmap. This makes page mapping works well through vm2 blkfront to vm1 
netback. However, when netback does grant copy, the error happens in 
this routine: __gnttab_copy->__get_paged_frame->get_page_from_gfn->get_page.
See /xen/arch/x86/mm.c get_page(),
     if ( likely(owner == domain) )
         return 1;
In above if condition, the src page is from vm2, so owner is id of vm2, 
domain is 0 here. Then get_page return 0, hence get_page_from_gfn return 
NULL and __get_paged_frame return GNTST_bad_page. Finally, put_page is 
called in __grant_copy directly and grant copy fails in netback. As a 
result, writing to nfsfile fails and this results damage to nfsfile, 
then vm can not be rebooted successfully.

Disable the nfs direct io can be a workaround, however, this will cause 
performance penalty. Or any copy is involved between vm2 blkfront->vm1 
netback probably helps in this case. But zerocopy is the best thing for 
performance, so any suggestions for this issue?

This issue is pretty similar with this one 
http://lists.xen.org/archives/html/xen-devel/2012-12/msg01722.html. 
Roger, did you fix this issue in your case?

Thanks
Annie

             reply	other threads:[~2014-07-16 20:36 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-16 20:36 annie li [this message]
2014-07-17 15:49 ` Rebooting domu fails in nfs share exported from another domu on the same dom0 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
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=53C6E24D.7050903@oracle.com \
    --to=annie.li@oracle.com \
    --cc=roger.pau@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).