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

[Ed White <edmund.h.white@xxxxxxxxx>]

On 06/29/2015 08:03 AM, George Dunlap wrote:
> 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.
> 

Exactly. After this patch, the hypervisor can enable #VE in the VMCS
but no #VE's will actually be delivered. A later patch selectively
enables them on certain EPTE's.

Ed

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