[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 02/12] VMX: implement suppress #VE.
On Mon, Jun 29, 2015 at 3:31 PM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote: > On 29/06/15 15:20, George Dunlap wrote: >> On Mon, Jun 22, 2015 at 7:56 PM, Ed White <edmund.h.white@xxxxxxxxx> 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 <edmund.h.white@xxxxxxxxx> >>> --- >>> 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. So the short answer is, 'yes': The hardware will deliver #VEs for all non-misconfigured ept entries (which includes entries which are simply not present) unless you actively do something to suppress them; what we want is *not* to deliver #VEs unless the guest actively does something to cause them to be delivered for particular GPAs. Ravi> correct, by setting suppress-ve in the default EPTE we achieve that behavior of not delivering #VE (ie legacy behavior) unless the guest actively sets an altp2m policy for specific GPAs. Ravi Thanks, -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |