[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 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?  So we now need to
actively choose a "default" which is different than the hardware?

 -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®.