From: Jaeyong Yoo <jaeyong.yoo@samsung.com>
To: xen-devel@lists.xen.org
Cc: Jaeyong Yoo <jaeyong.yoo@samsung.com>
Subject: [PATCH] ARM: cache coherence problem in guestcopy.c
Date: Tue, 18 Jun 2013 14:03:25 +0900 [thread overview]
Message-ID: <1371531805-31438-1-git-send-email-jaeyong.yoo@samsung.com> (raw)
I've encountered a rather unusual bug while I'm implementing live
migration on arndale board.
After resume, domU kernel starts invoking hypercalls and at some point
the hypercall parameters delivered to xen are corrupted.
After some debugging (with the help of HW debugger), I found that
cache polution happens, and here is the detailed sequence.
1) DomU kernel allocates a local variable struct xen_add_to_physmap xatp
and the GVA of xatp is 0xc785fe38 (note that not cache-line aligned)
(see gnttab_map function in linux/drivers/xen/grant-table.c)
2) GVA of xatp is mapped in xen page table at raw_copy_from_guest function,
and the VA of xen is 0xae48ee38 and its contents are cached.
3) DomU kernel reuses xatp to invoke the second hypercall with different
parameters.
4) GVA of xatp is mapped again in the same VA of xen, and the cached data
at step 2) (the first hypercall parameter) is loaded.
The below patch prevents the above problem.
I'm wondering, as a better solution, that does unmap_domain_page should
invalidate the cache before unmap the page?
Signed-off-by: Jaeyong Yoo <jaeyong.yoo@samsung.com>
---
xen/arch/arm/guestcopy.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
index d146cd6..9c4a7e4 100644
--- a/xen/arch/arm/guestcopy.c
+++ b/xen/arch/arm/guestcopy.c
@@ -25,6 +25,7 @@ unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
p += offset;
memcpy(p, from, size);
+ flush_xen_dcache_va_range(p, size);
unmap_domain_page(p - offset);
len -= size;
from += size;
@@ -55,6 +56,7 @@ unsigned long raw_clear_guest(void *to, unsigned len)
p += offset;
memset(p, 0x00, size);
+ flush_xen_dcache_va_range(p, size);
unmap_domain_page(p - offset);
len -= size;
to += size;
@@ -84,6 +86,7 @@ unsigned long raw_copy_from_guest(void *to, const void __user *from, unsigned le
memcpy(to, p, size);
+ flush_xen_dcache_va_range(p, size);
unmap_domain_page(p);
len -= size;
from += size;
--
1.7.9.5
next reply other threads:[~2013-06-18 5:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-18 5:03 Jaeyong Yoo [this message]
2013-06-18 9:20 ` [PATCH] ARM: cache coherence problem in guestcopy.c Ian Campbell
-- strict thread matches above, loose matches on Subject: below --
2013-06-18 11:22 Jaeyong Yoo
2013-06-18 11:45 ` Ian Campbell
2013-06-18 12:05 Jaeyong Yoo
2013-06-18 12:18 ` Ian Campbell
2013-06-19 15:12 ` Ian Campbell
2013-06-20 11:55 ` Stefano Stabellini
2013-06-20 12:19 ` Tim Deegan
2013-06-25 9:43 ` Ian Campbell
2013-06-20 8:34 Jaeyong Yoo
2013-06-25 9:22 ` Ian Campbell
2013-07-02 9:38 ` Ian Campbell
2013-07-02 12:14 ` Sengul Thomas
2013-07-02 12:24 ` Sengul Thomas
2013-07-02 12:33 ` Ian Campbell
2013-07-02 12:39 ` Sengul Thomas
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=1371531805-31438-1-git-send-email-jaeyong.yoo@samsung.com \
--to=jaeyong.yoo@samsung.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).