All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Huaitong Han <huaitong.han@intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>,
	"george.dunlap@eu.citrix.com" <george.dunlap@eu.citrix.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jun Nakajima <jun.nakajima@intel.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [PATCH V4 4/6] x86/hvm: pkeys, add pkeys support for guest_walk_tables
Date: Tue, 22 Dec 2015 01:43:58 -0700	[thread overview]
Message-ID: <56791B5E02000078000C220F@prv-mh.provo.novell.com> (raw)
In-Reply-To: <1450771932.4024.18.camel@intel.com>

>>> On 22.12.15 at 09:12, <huaitong.han@intel.com> wrote:
> On Mon, 2015-12-21 at 08:32 -0700, Jan Beulich wrote:
>> > > > On 21.12.15 at 08:21, <huaitong.han@intel.com> wrote:
>> > --- a/xen/arch/x86/mm/guest_walk.c
>> > +++ b/xen/arch/x86/mm/guest_walk.c
>> > @@ -90,6 +90,55 @@ static uint32_t set_ad_bits(void *guest_p, void
>> > *walk_p, int set_dirty)
>> >      return 0;
>> >  }
>> >  
>> > +#if GUEST_PAGING_LEVELS >= CONFIG_PAGING_LEVELS
>> 
>> GUEST_PAGING_LEVELS >= 4 (just like further down)
> The code is modified according Andrew's comments:
> "
>   This is a latent linking bug for the future 
>   when 5 levels comes along.
> 
>   It will probably be best to use the same trick
>   as gw_page_flags to compile it once but use it
>   multiple times.
> "

Okay, understood. But then you should follow _that_ model (using
== instead of >=) instead of inventing a 3rd variant. Similar things
should be done in similar ways so that they can be easily recognized
being similar.

Otoh the function isn't being called from code other than
GUEST_PAGING_LEVELS == 4, so at present it could be static,
which would take care of the latent linking issue Andrew referred to.

>> > +    bool_t pf = !!(pfec & PFEC_page_present);
>> > +    bool_t uf = !!(pfec & PFEC_user_mode);
>> > +    bool_t wf = !!(pfec & PFEC_write_access);
>> > +    bool_t ff = !!(pfec & PFEC_insn_fetch);
>> > +    bool_t rsvdf = !!(pfec & PFEC_reserved_bit);
>> > +
>> > +    /* When page is present,  PFEC_prot_key is always checked */
>> > +    if ( !pf || is_pv_vcpu(vcpu) )
>> > +        return 0;
>> 
>> I think for a function called "check" together with how its callers
>> use
>> it the return value meaning is inverted here. 
> I will change the function name to "pkey_page_fault".

Perhaps just pkey_fault() then, since it's clear there's no other fault
possible here besides a page fault?

>> Also the comment seems
>> inverted wrt the actual check (and is missing a full stop). And
>> doesn't
>> key 0 have static meaning, in which case you could bail early (and
>> namely avoid the expensive RDPKRU further down)?
> Key 0 have no static meaning, the default key maybe different in
> different OS.

Okay - I thought I had seen something like this mentioned in
another sub-thread.

>> > @@ -270,6 +324,12 @@ guest_walk_tables(struct vcpu *v, struct
>> > p2m_domain *p2m,
>> >  
>> >      pse2M = (gflags & _PAGE_PSE) && guest_supports_superpages(v); 
>> >  
>> > +#if GUEST_PAGING_LEVELS >= 4
>> > +    pkey = guest_l2e_get_pkey(gw->l2e);
>> > +    if ( pse2M && leaf_pte_pkeys_check(v, pfec, pkey) )
>> > +        rc |= _PAGE_PKEY_BITS;
>> > +#endif
>> 
>> I think the #ifdef isn't really needed here, if you moved the one
>> around leaf_pte_pkeys_check() into that function, and if you
>> perhaps also dropped the "pkey" local variable.
> guest_l2e_get_pkey has different macro depend on GUEST_PAGING_LEVELS
> too, and I think it's better to keep it.

I didn't suggest to drop guest_l2e_get_pkey(). I'd like to see the
#ifdef-s go away if at all possible, to help code readability.

Jan

  reply	other threads:[~2015-12-22  8:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-21  7:21 [PATCH V4 0/6] x86/hvm: pkeys, add memory protection-key support Huaitong Han
2015-12-21  7:21 ` [PATCH V4 1/6] x86/hvm: pkeys, add the flag to enable Memory Protection Keys Huaitong Han
2015-12-21 12:58   ` Jan Beulich
2015-12-21  7:21 ` [PATCH V4 2/6] x86/hvm: pkeys, add pkeys support when setting CR4 Huaitong Han
2015-12-21 15:00   ` Jan Beulich
2015-12-21  7:21 ` [PATCH V4 3/6] x86/hvm: pkeys, disable pkeys for guests in non-paging mode Huaitong Han
2015-12-21  7:21 ` [PATCH V4 4/6] x86/hvm: pkeys, add pkeys support for guest_walk_tables Huaitong Han
2015-12-21 15:32   ` Jan Beulich
2015-12-22  8:12     ` Han, Huaitong
2015-12-22  8:43       ` Jan Beulich [this message]
2015-12-21  7:21 ` [PATCH V4 5/6] x86/hvm: pkeys, add xstate support for pkeys Huaitong Han
2015-12-21 15:09   ` Jan Beulich
2015-12-21  7:21 ` [PATCH V4 6/6] x86/hvm: pkeys, add pkeys support for cpuid handling Huaitong Han
2015-12-21 15:07   ` Jan Beulich
2015-12-22  2:54     ` Han, Huaitong
2015-12-22  8:30       ` Jan Beulich
2015-12-22  9:25         ` Han, Huaitong
2015-12-22  9:51           ` Jan Beulich

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=56791B5E02000078000C220F@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=huaitong.han@intel.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jun.nakajima@intel.com \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.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.