All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Wu, Feng" <feng.wu@intel.com>,
	"gleb@redhat.com" <gleb@redhat.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH 2/4] KVM: Add SMAP support when setting CR4
Date: Mon, 31 Mar 2014 09:28:53 +0200	[thread overview]
Message-ID: <53391935.3040908@redhat.com> (raw)
In-Reply-To: <E959C4978C3B6342920538CF579893F001E8E453@SHSMSX104.ccr.corp.intel.com>

Il 31/03/2014 08:16, Wu, Feng ha scritto:
> --------------------------------------------------------------------------------------------------------------------
> /*
>  * If CPL < 3, SMAP protections are disabled if EFLAGS.AC = 1.
>  *
>  * If CPL = 3, SMAP applies to all supervisor-mode data accesses
>  * (these are implicit supervisor accesses) regardless of the value
>  * of EFLAGS.AC.
>  *
>  * This computes (cpl < 3) && (rflags & X86_EFLAGS_AC), leaving
>  * the result in X86_EFLAGS_AC. We then insert it in place of
>  * the PFERR_RSVD_MASK bit; this bit will always be zero in pfec,
>  * but it will be one in index if SMAP checks are being overridden.
>  * It is important to keep this branchless.
>  */
> smap = (cpl - 3) & (rflags & X86_EFLAGS_AC);
> index =
>         (pfec >> 1) +
>         (smap >> (X86_EFLAGS_AC_BIT - PFERR_RSVD_BIT + 1));
>
> return (mmu->permissions[index] >> pte_access) & 1;
>
> The direction of PFERR_RSVD_MASK is the opposite compared to your code.
> -------------------------------------------------------------------------------------------------------------------

Correct.

> I am a little confused about some points of the above code:
> 1. "smap = (cpl - 3) & (rflags & X86_EFLAGS_AC);"
> "smap" equals 1 when it is overridden and it is 0 when being enforced.

Actually, smap equals X86_EFLAGS_AC when it is overridden.  Perhaps this 
is the source of the confusion.  Note that I'm using &, not &&.

> So "index"
> will be (pfec >> 1) when SMAP is enforced, but in my understanding of this case, we
> should use the index with PFERR_RSVD_MASK bit being 1 in mmu-> permissions[]
> to check the fault.
> 2. " smap >> (X86_EFLAGS_AC_BIT - PFERR_RSVD_BIT + 1)"
> I am not quite understand this line. BTW, I cannot find the definition of "PFERR_RSVD_BIT",
> Do you mean PFERR_RSVD_BIT equals 3?

Yes.  You can similarly add PFERR_PRESENT_BIT (equal to 0) etc.

> I think the basic idea is using group 0 to check permission faults when !((cpl - 3) & (rflags & X86_EFLAGS_AC)), that is SMAP is overridden
> while using group 1 to check faults when (cpl - 3) & (rflags & X86_EFLAGS_AC), that is SMAP is enforced.
>
> Here is the code base on your proposal in my understanding:
>
> -------------------------------------------------------------------------------------------------------------------
> smap = !((cpl - 3) & (rflags & X86_EFLAGS_AC));
> index =
>         (pfec >> 1) + (smap << (PFERR_RSVD_BIT - 1)); /*assuming PFERR_RSVD_BIT == 3*/
>
> return (mmu->permissions[index] >> pte_access) & 1;
> -------------------------------------------------------------------------------------------------------------------
>
> Could you please have a look at it? Appreciate your help! :)

It is faster if you avoid the "!" and shift right from the AC bit into 
position PFERR_RSVD_BIT - 1.  In update_permission_bitmask you can 
invert the direction of the bit when you extract it from pfec.

Paolo


  reply	other threads:[~2014-03-31  7:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-28 17:36 [PATCH 0/4] KVM: enable Intel SMAP for KVM Feng Wu
2014-03-28 17:36 ` [PATCH 1/4] KVM: Remove SMAP bit from CR4_RESERVED_BITS Feng Wu
2014-03-28 17:36 ` [PATCH 2/4] KVM: Add SMAP support when setting CR4 Feng Wu
2014-03-28 12:03   ` Paolo Bonzini
2014-03-28 14:03     ` Wu, Feng
2014-03-31  6:16     ` Wu, Feng
2014-03-31  7:28       ` Paolo Bonzini [this message]
2014-03-31  8:06         ` Wu, Feng
2014-03-31  8:45           ` Paolo Bonzini
2014-03-28 17:36 ` [PATCH 3/4] KVM: Disable SMAP for guests in EPT realmode and EPT unpaging mode Feng Wu
2014-03-28 17:36 ` [PATCH 4/4] KVM: expose SMAP feature to guest Feng Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53391935.3040908@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=feng.wu@intel.com \
    --cc=gleb@redhat.com \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.