From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@novell.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: regression from c/s 22071:c5aed2e049bc (ept: Put locks around ept_get_entry) ?
Date: Thu, 16 Dec 2010 20:34:50 +0000 [thread overview]
Message-ID: <C930286C.29670%keir@xen.org> (raw)
In-Reply-To: <C92FF6CF.295FC%keir@xen.org>
[-- Attachment #1: Type: text/plain, Size: 908 bytes --]
On 16/12/2010 17:03, "Keir Fraser" <keir@xen.org> wrote:
> On 16/12/2010 16:50, "Jan Beulich" <JBeulich@novell.com> wrote:
>
>>> approach therefore. Perhaps *(volatile type *)px = x or, really, even better
>>> I should define some {read,write}_atomic{8,16,32,64} accessor functions
>>> which use inline asm to absolutely definitely emit a single atomic 'mov'
>>> instruction.
>>>
>>> Make sense?
>>
>> Yes.
>
> Excellent. I will lay groundwork and fix pte_{read,write}_atomic directly in
> -unstable and -4.0-testing. I will then post a proposed fix for EPT to the
> list. I don't know that code so well and I may not otherwise catch all
> places that require use of the new accessor macros.
Attached is a patch I've knocked up for p2m-ept.c. I don't know how complete
it really is. Perhaps someone (George?) would like to Ack it as is, or
develop it further.
-- Keir
> -- Keir
>
>> Jan
>>
>
>
[-- Attachment #2: 00-ept-atomic --]
[-- Type: application/octet-stream, Size: 3122 bytes --]
diff -r f5f3cf4e001f xen/arch/x86/mm/hap/p2m-ept.c
--- a/xen/arch/x86/mm/hap/p2m-ept.c Thu Dec 16 20:07:03 2010 +0000
+++ b/xen/arch/x86/mm/hap/p2m-ept.c Thu Dec 16 20:29:01 2010 +0000
@@ -32,6 +32,11 @@
#include <xen/keyhandler.h>
#include <xen/softirq.h>
+#define atomic_read_ept_entry(__pepte) \
+ ( (ept_entry_t) { .epte = atomic_read64(&(__pepte)->epte) } )
+#define atomic_write_ept_entry(__pepte, __epte) \
+ atomic_write64(&(__pepte)->epte, (__epte).epte)
+
#define is_epte_present(ept_entry) ((ept_entry)->epte & 0x7)
#define is_epte_superpage(ept_entry) ((ept_entry)->sp)
@@ -222,7 +227,7 @@
/* ept_next_level() is called (sometimes) without a lock. Read
* the entry once, and act on the "cached" entry after that to
* avoid races. */
- e=*ept_entry;
+ e = atomic_read_ept_entry(ept_entry);
if ( !is_epte_present(&e) )
{
@@ -235,7 +240,7 @@
if ( !ept_set_middle_entry(p2m, ept_entry) )
return GUEST_TABLE_MAP_FAILED;
else
- e=*ept_entry; /* Refresh */
+ e = atomic_read_ept_entry(ept_entry); /* Refresh */
}
/* The only time sp would be set here is if we had hit a superpage */
@@ -317,6 +322,7 @@
if ( i == target )
{
/* We reached the target level. */
+ ept_entry_t new_entry = { .epte = 0 };
/* No need to flush if the old entry wasn't valid */
if ( !is_epte_present(ept_entry) )
@@ -325,8 +331,6 @@
if ( mfn_valid(mfn_x(mfn)) || direct_mmio || p2m_is_paged(p2mt) ||
(p2mt == p2m_ram_paging_in_start) )
{
- ept_entry_t new_entry = { .epte = 0 };
-
/* Construct the new entry, and then write it once */
new_entry.emt = epte_get_entry_emt(p2m->domain, gfn, mfn, &ipat,
direct_mmio);
@@ -341,11 +345,9 @@
new_entry.mfn = mfn_x(mfn);
ept_p2m_type_to_flags(&new_entry, p2mt);
+ }
- ept_entry->epte = new_entry.epte;
- }
- else
- ept_entry->epte = 0;
+ atomic_write_ept_entry(ept_entry, new_entry);
}
else
{
@@ -355,7 +357,7 @@
ASSERT(is_epte_superpage(ept_entry));
- split_ept_entry = *ept_entry;
+ split_ept_entry = atomic_read_ept_entry(ept_entry);
if ( !ept_split_super_page(p2m, &split_ept_entry, i, target) )
{
@@ -365,7 +367,7 @@
/* now install the newly split ept sub-tree */
/* NB: please make sure domian is paused and no in-fly VT-d DMA. */
- *ept_entry = split_ept_entry;
+ atomic_write_ept_entry(ept_entry, split_ept_entry);
/* then move to the level we want to make real changes */
for ( ; i > target; i-- )
@@ -391,7 +393,7 @@
ept_p2m_type_to_flags(&new_entry, p2mt);
- ept_entry->epte = new_entry.epte;
+ atomic_write_ept_entry(ept_entry, new_entry);
}
/* Track the highest gfn for which we have ever had a valid mapping */
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2010-12-16 20:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-14 8:39 regression from c/s 22071:c5aed2e049bc (ept: Put locks around ept_get_entry) ? Jan Beulich
2010-12-14 10:47 ` George Dunlap
2010-12-14 10:48 ` George Dunlap
2010-12-14 12:37 ` Jan Beulich
2010-12-14 14:32 ` George Dunlap
2010-12-14 14:34 ` George Dunlap
2010-12-14 14:50 ` Jan Beulich
2010-12-16 15:51 ` Jan Beulich
2010-12-16 16:12 ` Keir Fraser
2010-12-16 16:22 ` Jan Beulich
2010-12-16 16:42 ` Keir Fraser
2010-12-16 16:50 ` Jan Beulich
2010-12-16 17:03 ` Keir Fraser
2010-12-16 20:34 ` Keir Fraser [this message]
2010-12-17 11:15 ` Tim Deegan
2010-12-20 16:24 ` George Dunlap
2010-12-17 14:03 ` Olaf Hering
2010-12-17 14:18 ` Keir Fraser
2010-12-16 16:59 ` Keir Fraser
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=C930286C.29670%keir@xen.org \
--to=keir@xen.org \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@novell.com \
--cc=xen-devel@lists.xensource.com \
/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).