[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.