xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH 3/3] x86/pv: Compile out compat_gdt in !CONFIG_PV builds
Date: Mon, 20 Apr 2020 17:47:10 +0200	[thread overview]
Message-ID: <cb6fcbd0-1b0a-d105-30ce-e0a6215f4904@suse.com> (raw)
In-Reply-To: <acffe7f9-3265-e999-34ce-30891535897b@citrix.com>

On 20.04.2020 16:39, Andrew Cooper wrote:
> On 20/04/2020 15:12, Jan Beulich wrote:
>> On 17.04.2020 17:50, Andrew Cooper wrote:
>>> There is no need for the Compat GDT if there are no 32bit PV guests.  This
>>> saves 4k per online CPU
>>>
>>> Bloat-o-meter reports the following savings in Xen itself:
>>>
>>>   add/remove: 0/3 grow/shrink: 1/4 up/down: 7/-4612 (-4605)
>>>   Function                                     old     new   delta
>>>   cpu_smpboot_free                            1249    1256      +7
>>>   per_cpu__compat_gdt_l1e                        8       -      -8
>>>   per_cpu__compat_gdt                            8       -      -8
>>>   init_idt_traps                               442     420     -22
>>>   load_system_tables                           414     364     -50
>>>   trap_init                                    444     280    -164
>>>   cpu_smpboot_callback                        1255     991    -264
>>>   boot_compat_gdt                             4096       -   -4096
>>>   Total: Before=3062726, After=3058121, chg -0.15%
>>>
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>> ---
>>> CC: Jan Beulich <JBeulich@suse.com>
>>> CC: Wei Liu <wl@xen.org>
>>> CC: Roger Pau Monné <roger.pau@citrix.com>
>>>
>>> The increase in cpu_smpboot_free() appears to be a consequence of a totally
>>> different layout of basic blocks.
>>> ---
>>>  xen/arch/x86/cpu/common.c |  5 +++--
>>>  xen/arch/x86/desc.c       |  2 ++
>>>  xen/arch/x86/smpboot.c    |  5 ++++-
>>>  xen/arch/x86/traps.c      | 10 +++++++---
>>>  4 files changed, 16 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
>>> index 1b33f1ed71..7b093cb421 100644
>>> --- a/xen/arch/x86/cpu/common.c
>>> +++ b/xen/arch/x86/cpu/common.c
>>> @@ -752,8 +752,9 @@ void load_system_tables(void)
>>>  
>>>  	_set_tssldt_desc(gdt + TSS_ENTRY, (unsigned long)tss,
>>>  			 sizeof(*tss) - 1, SYS_DESC_tss_avail);
>>> -	_set_tssldt_desc(compat_gdt + TSS_ENTRY, (unsigned long)tss,
>>> -			 sizeof(*tss) - 1, SYS_DESC_tss_busy);
>>> +	if ( IS_ENABLED(CONFIG_PV32) )
>>> +		_set_tssldt_desc(compat_gdt + TSS_ENTRY, (unsigned long)tss,
>>> +				 sizeof(*tss) - 1, SYS_DESC_tss_busy);
>> Wouldn't this better be "if ( opt_pv32 )"? Also elsewhere then.
> 
> Doing it like this specifically ensures that there is never a case where
> things are half configured.

But this way you set up something in the GDT that's never going
to be used when "pv=no-32". Why leave a TSS accessible that we
don't need?

> I don't think it is wise to suggest that making opt_pv32 runtime
> configurable might work.

I didn't suggest (nor even consider) runtime changing of this
setting. If we wanted, _that_ would be what might require using
code as you have it right now (if we wanted to avoid setting
this up at the time the setting gets flipped from false to true).

Jan


  reply	other threads:[~2020-04-20 15:47 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-17 15:50 [PATCH 0/3] x86/pv: Start to trim 32bit support Andrew Cooper
2020-04-17 15:50 ` [PATCH 1/3] x86/pv: Options to disable and/or compile out 32bit PV support Andrew Cooper
2020-04-20 13:47   ` Roger Pau Monné
2020-04-20 17:31     ` Andrew Cooper
2020-04-20 14:05   ` Jan Beulich
2020-04-20 18:05     ` Andrew Cooper
2020-04-21  6:02       ` Jan Beulich
2020-04-23 17:35         ` Andrew Cooper
2020-04-24  5:28           ` Jürgen Groß
2020-04-27 20:02             ` Andrew Cooper
2020-04-24  6:11           ` Jan Beulich
2020-04-20 14:15   ` Jan Beulich
2020-04-29 13:06   ` [PATCH v2 " Andrew Cooper
2020-04-29 13:55     ` Jan Beulich
2020-04-17 15:50 ` [PATCH 2/3] x86/pv: Short-circuit is_pv_{32, 64}bit_domain() in !CONFIG_PV32 builds Andrew Cooper
2020-04-20 14:09   ` [PATCH 2/3] x86/pv: Short-circuit is_pv_{32,64}bit_domain() " Jan Beulich
2020-04-29 13:13     ` Andrew Cooper
2020-04-29 13:29       ` Jan Beulich
2020-04-29 13:30         ` Andrew Cooper
2020-04-29 13:37           ` Jan Beulich
2020-04-17 15:50 ` [PATCH 3/3] x86/pv: Compile out compat_gdt in !CONFIG_PV builds Andrew Cooper
2020-04-20 14:12   ` Jan Beulich
2020-04-20 14:39     ` Andrew Cooper
2020-04-20 15:47       ` Jan Beulich [this message]
2020-04-20 17:08         ` Andrew Cooper
2020-04-21  6:09           ` Jan Beulich
2020-04-18 13:46 ` [PATCH 0/3] x86/pv: Start to trim 32bit support Wei Liu

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=cb6fcbd0-1b0a-d105-30ce-e0a6215f4904@suse.com \
    --to=jbeulich@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).