All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: xen-devel <xen-devel@lists.xenproject.org>
Cc: Keir Fraser <keir@xen.org>, Kevin Tian <kevin.tian@intel.com>,
	Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>, Tim Deegan <tim@xen.org>
Subject: [PATCH] x86/EPT: flush cache when (potentially) limiting cachability
Date: Fri, 25 Apr 2014 13:13:05 +0100	[thread overview]
Message-ID: <535A6D71020000780000C4B4@nat28.tlf.novell.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

While generally such guest side changes ought to be followed by guest
initiated flushes, we're flushing the cache under similar conditions
elsewhere (e.g. when the guest sets CR0.CD), so let's do so here too.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Note that this goes on top of the still pending series titled
"x86/EPT: miscellaneous further fixes to EMT determination" (see
http://lists.xenproject.org/archives/html/xen-devel/2014-04/msg02932.html).

It would need to be determined whether we should gate all of these
flushes on need_iommu() and/or cache_flush_permitted(). Otoh the
changes they hang off of are infrequent, so there's no severe
performance penalty.

--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -649,8 +649,11 @@ int32_t hvm_set_mem_pinned_cacheattr(
             {
                 rcu_read_unlock(&pinned_cacheattr_rcu_lock);
                 list_del_rcu(&range->list);
+                type = range->type;
                 call_rcu(&range->rcu, free_pinned_cacheattr_entry);
                 p2m_memory_type_changed(d);
+                if ( type != PAT_TYPE_UNCACHABLE )
+                    flush_all(FLUSH_CACHE);
                 return 0;
             }
         rcu_read_unlock(&pinned_cacheattr_rcu_lock);
@@ -697,6 +700,8 @@ int32_t hvm_set_mem_pinned_cacheattr(
 
     list_add_rcu(&range->list, &d->arch.hvm_domain.pinned_cacheattr_ranges);
     p2m_memory_type_changed(d);
+    if ( type != PAT_TYPE_WRBACK )
+        flush_all(FLUSH_CACHE);
 
     return 0;
 }
@@ -786,7 +791,10 @@ HVM_REGISTER_SAVE_RESTORE(MTRR, hvm_save
 void memory_type_changed(struct domain *d)
 {
     if ( iommu_enabled && d->vcpu && d->vcpu[0] )
+    {
         p2m_memory_type_changed(d);
+        flush_all(FLUSH_CACHE);
+    }
 }
 
 int epte_get_entry_emt(struct domain *d, unsigned long gfn, mfn_t mfn,




[-- Attachment #2: EPT-flush-cache.patch --]
[-- Type: text/plain, Size: 1960 bytes --]

x86/EPT: flush cache when (potentially) limiting cachability

While generally such guest side changes ought to be followed by guest
initiated flushes, we're flushing the cache under similar conditions
elsewhere (e.g. when the guest sets CR0.CD), so let's do so here too.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Note that this goes on top of the still pending series titled
"x86/EPT: miscellaneous further fixes to EMT determination" (see
http://lists.xenproject.org/archives/html/xen-devel/2014-04/msg02932.html).

It would need to be determined whether we should gate all of these
flushes on need_iommu() and/or cache_flush_permitted(). Otoh the
changes they hang off of are infrequent, so there's no severe
performance penalty.

--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -649,8 +649,11 @@ int32_t hvm_set_mem_pinned_cacheattr(
             {
                 rcu_read_unlock(&pinned_cacheattr_rcu_lock);
                 list_del_rcu(&range->list);
+                type = range->type;
                 call_rcu(&range->rcu, free_pinned_cacheattr_entry);
                 p2m_memory_type_changed(d);
+                if ( type != PAT_TYPE_UNCACHABLE )
+                    flush_all(FLUSH_CACHE);
                 return 0;
             }
         rcu_read_unlock(&pinned_cacheattr_rcu_lock);
@@ -697,6 +700,8 @@ int32_t hvm_set_mem_pinned_cacheattr(
 
     list_add_rcu(&range->list, &d->arch.hvm_domain.pinned_cacheattr_ranges);
     p2m_memory_type_changed(d);
+    if ( type != PAT_TYPE_WRBACK )
+        flush_all(FLUSH_CACHE);
 
     return 0;
 }
@@ -786,7 +791,10 @@ HVM_REGISTER_SAVE_RESTORE(MTRR, hvm_save
 void memory_type_changed(struct domain *d)
 {
     if ( iommu_enabled && d->vcpu && d->vcpu[0] )
+    {
         p2m_memory_type_changed(d);
+        flush_all(FLUSH_CACHE);
+    }
 }
 
 int epte_get_entry_emt(struct domain *d, unsigned long gfn, mfn_t mfn,

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

             reply	other threads:[~2014-04-25 12:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-25 12:13 Jan Beulich [this message]
2014-05-01 13:39 ` [PATCH] x86/EPT: flush cache when (potentially) limiting cachability Tim Deegan
2014-05-30  2:07 ` Liu, SongtaoX
2014-05-30  6:26   ` Jan Beulich
2014-05-30  7:02     ` Jan Beulich
2014-05-30  7:34       ` Liu, SongtaoX
2014-05-30 11:20         ` Jan Beulich
2014-06-12  1:28           ` Liu, SongtaoX
2014-06-12  8:43             ` Ian Campbell
2014-06-16 13:01             ` Jan Beulich
2014-06-17  2:19               ` Liu, SongtaoX
2014-06-17  7:11                 ` Jan Beulich
2014-06-17  8:33                   ` Liu, SongtaoX
2014-06-17 15:34                     ` Jan Beulich
2014-06-18  3:09                       ` Liu, SongtaoX
2014-06-18 10:02                         ` Jan Beulich

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=535A6D71020000780000C4B4@nat28.tlf.novell.com \
    --to=jbeulich@suse.com \
    --cc=eddie.dong@intel.com \
    --cc=jun.nakajima@intel.com \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.