Re: [Xen-devel] [PATCH v2 02/12] VMX: implement suppress #VE.

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

~Andrew

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