All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	AndrewCooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH 3/9] x86/mm: honor opt_pcid also for 32-bit PV domains
Date: Thu, 12 Sep 2019 12:45:33 +0200	[thread overview]
Message-ID: <56a7bf8f-74b6-7d69-f6e5-30644e677869@suse.com> (raw)
In-Reply-To: <20190912103441.le4zets5ey73uxwl@Air-de-Roger>

On 12.09.2019 12:34, Roger Pau Monné  wrote:
> On Wed, Sep 11, 2019 at 05:22:51PM +0200, Jan Beulich wrote:
>> I can't see any technical or performance reason why we should treat
>> 32-bit PV different from 64-bit PV in this regard.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> The original commit mentions that PCID doesn't improve performance for
> non-XPTI domains, but it doesn't mention whether it makes performance
> worse.

Well, yes - it's not like we're defaulting to using PCID now for
32-bit guests. But we allow people to turn on its use. After all
the original measurements were done on a limited set of hardware,
and hardware also changes/advances all the time.

> The change LGTM, if you are fine performance wise:
> 
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks.

>> --- a/xen/arch/x86/pv/domain.c
>> +++ b/xen/arch/x86/pv/domain.c
>> @@ -180,7 +180,24 @@ int switch_compat(struct domain *d)
>>      d->arch.x87_fip_width = 4;
>>  
>>      d->arch.pv.xpti = false;
>> -    d->arch.pv.pcid = false;
>> +
>> +    if ( use_invpcid && cpu_has_pcid )
>> +        switch ( ACCESS_ONCE(opt_pcid) )
>> +        {
>> +        case PCID_OFF:
>> +        case PCID_XPTI:
>> +            d->arch.pv.pcid = false;
>> +            break;
>> +
>> +        case PCID_ALL:
>> +        case PCID_NOXPTI:
>> +            d->arch.pv.pcid = true;
>> +            break;
>> +
>> +        default:
>> +            ASSERT_UNREACHABLE();
>> +            break;
>> +        }
> 
> This chunk is (functionality wise) exactly the same as the one in
> pv_domain_initialise, it might be good to put this in a separate
> helper?

Could be, indeed, but would at least double the size of this patch.
I wasn't convinced that's worth it. I'll see what Andrew thinks,
since I'll need his ack anyway (at least in my understanding of the
still un-refined, un-written rules of what is necessary for
committing a maintainer's patch).

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-09-12 10:46 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-11 15:15 [Xen-devel] [PATCH RESEND/PING 0/9] XSA-292 follow-up Jan Beulich
2019-09-11 15:21 ` [Xen-devel] [PATCH 1/9] x86: adjust cr3_pcid() return type Jan Beulich
2019-09-12  9:19   ` Roger Pau Monné
2019-09-11 15:22 ` [Xen-devel] [PATCH 2/9] x86: limit the amount of TLB flushing in switch_cr3_cr4() Jan Beulich
2019-09-12  9:54   ` Roger Pau Monné
2019-09-12 10:11     ` Jan Beulich
2019-09-12 10:38       ` Roger Pau Monné
2019-09-11 15:22 ` [Xen-devel] [PATCH 3/9] x86/mm: honor opt_pcid also for 32-bit PV domains Jan Beulich
2019-09-12 10:34   ` Roger Pau Monné
2019-09-12 10:45     ` Jan Beulich [this message]
2019-09-11 15:23 ` [Xen-devel] [PATCH 4/9] x86/HVM: move NOFLUSH handling out of hvm_set_cr3() Jan Beulich
2019-09-12 11:35   ` Roger Pau Monné
2019-09-12 11:52     ` Jan Beulich
2019-09-12 14:44       ` Roger Pau Monné
2019-09-12 14:47         ` Jan Beulich
2019-09-12 15:42           ` Roger Pau Monné
2019-09-12 15:52             ` Jan Beulich
2019-09-11 15:24 ` [Xen-devel] [PATCH 5/9] x86/HVM: refuse CR3 loads with reserved (upper) bits set Jan Beulich
2019-09-12 11:45   ` Roger Pau Monné
2019-09-12 12:01     ` Jan Beulich
2019-09-11 15:25 ` [Xen-devel] [PATCH 6/9] x86/HVM: relax shadow mode check in hvm_set_cr3() Jan Beulich
2019-09-12 14:50   ` Roger Pau Monné
2019-09-11 15:25 ` [Xen-devel] [PATCH 7/9] x86/HVM: cosmetics to hvm_set_cr3() Jan Beulich
2019-09-12 15:04   ` Roger Pau Monné
2019-09-11 15:26 ` [Xen-devel] [PATCH 8/9] x86/CPUID: drop INVPCID dependency on PCID Jan Beulich
2019-09-12 15:11   ` Roger Pau Monné
2019-09-11 15:26 ` [Xen-devel] [PATCH 9/9] x86: PCID is unused when !PV Jan Beulich
2019-09-12 15:31   ` Roger Pau Monné
2019-09-12 15:46     ` Jan Beulich
2019-09-12 15:48     ` Jan Beulich
2019-09-12 15:57       ` Roger Pau Monné
  -- strict thread matches above, loose matches on Subject: below --
2019-05-02 11:35 [PATCH 0/9] XSA-292 follow-up Jan Beulich
2019-05-02 12:19 ` [Xen-devel] [PATCH 3/9] x86/mm: honor opt_pcid also for 32-bit PV domains Jan Beulich
2019-05-02 12:19   ` 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=56a7bf8f-74b6-7d69-f6e5-30644e677869@suse.com \
    --to=jbeulich@suse.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.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.