From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v2 02/12] VMX: implement suppress #VE. Date: Mon, 29 Jun 2015 15:31:57 +0100 Message-ID: <559156DD.8080603@citrix.com> References: <1434999372-3688-1-git-send-email-edmund.h.white@intel.com> <1434999372-3688-3-git-send-email-edmund.h.white@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap , Ed White Cc: Ravi Sahita , Wei Liu , Tim Deegan , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich , tlengyel@novetta.com, Daniel De Graaf List-Id: xen-devel@lists.xenproject.org On 29/06/15 15:20, George Dunlap wrote: > On Mon, Jun 22, 2015 at 7:56 PM, Ed White wrote: >> In preparation for selectively enabling #VE in a later patch, set >> suppress #VE on all EPTE's. >> >> Suppress #VE should always be the default condition for two reasons: >> it is generally not safe to deliver #VE into a guest unless that guest >> has been modified to receive it; and even then for most EPT violations only >> the hypervisor is able to handle the violation. >> >> Signed-off-by: Ed White >> --- >> xen/arch/x86/mm/p2m-ept.c | 25 ++++++++++++++++++++++++- >> 1 file changed, 24 insertions(+), 1 deletion(-) >> >> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c >> index a6c9adf..5de3387 100644 >> --- a/xen/arch/x86/mm/p2m-ept.c >> +++ b/xen/arch/x86/mm/p2m-ept.c >> @@ -41,7 +41,7 @@ >> #define is_epte_superpage(ept_entry) ((ept_entry)->sp) >> static inline bool_t is_epte_valid(ept_entry_t *e) >> { >> - return (e->epte != 0 && e->sa_p2mt != p2m_invalid); >> + return ((e->epte & ~(1ul << 63)) != 0 && e->sa_p2mt != p2m_invalid); > So just getting up to speed here: Is it the case that if #VE is > enabled in vmcs that a #VE will be delivered to the guest on any > invalid epte entry that doesn't contain this flag? There is a list of conditions which must be satisfied for a #VE to be injected instead of an EPT related VMexit. All EPT misconfiguration still exit to the hypervisor, but this suppress_ve bit allows the hypervisor to choose to whether a plain EPT permission violation exits to Xen, or injects a #VE. > So we now need to > actively choose a "default" which is different than the hardware? By default, setting suppress_ve on everything will cause everything to behave as before. Clearing suppress_ve is an optimisation to avoid a vmexit/vmentry for faults needing bouncing to an in-guest agent. ~Andrew