From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: "kvm list" <kvm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>, "X86 ML" <x86@kernel.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH RFC 3/3] x86/kvm/vmx: avoid expensive rdmsr for MSR_GS_BASE
Date: Mon, 05 Mar 2018 11:04:04 +0100 [thread overview]
Message-ID: <87zi3mzvmz.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <CALCETrVhRP5W8jS0a+_Kq8BqJatszz0vu6keB=M7kr5c=KLi4g@mail.gmail.com> (Andy Lutomirski's message of "Fri, 2 Mar 2018 20:20:54 +0000")
Andy Lutomirski <luto@kernel.org> writes:
> On Fri, Mar 2, 2018 at 10:55 AM, Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
>> vmx_save_host_state() is only called from kvm_arch_vcpu_ioctl_run() so
>> the context is pretty well defined and as we're past 'swapgs' MSR_GS_BASE
>> should contain kernel's GS base which we point to irq_stack_union.
>>
>> irq_stack_union needs to be exported as KVM can be a module.
>>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>> arch/x86/kernel/cpu/common.c | 1 +
>> arch/x86/kvm/vmx.c | 3 ++-
>> 2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
>> index 348cf4821240..057393711093 100644
>> --- a/arch/x86/kernel/cpu/common.c
>> +++ b/arch/x86/kernel/cpu/common.c
>> @@ -1398,6 +1398,7 @@ __setup("clearcpuid=", setup_clearcpuid);
>> #ifdef CONFIG_X86_64
>> DEFINE_PER_CPU_FIRST(union irq_stack_union,
>> irq_stack_union) __aligned(PAGE_SIZE) __visible;
>> +EXPORT_PER_CPU_SYMBOL(irq_stack_union);
>
> GPL.
>
> Also, can you add a static inline unsigned long
> this_cpu_kernelmode_gs_base() that returns the actual value and then
> use it here and in arch/x86/cpu/common.c? I really don't like the way
> that KVM code hardcodes all kinds of assumptions about how the rest of
> the x86 code works rather than improving the x86 code to have the
> right hooks for KVM's use.
Sure, will do.
Doing plain rdmsr() in KVM is definitely cleaner and less fragile but
assuming 240 cpu cycles I'm cutting with this series justify the
increased complexity suggestions to avoid hardcoding x86 internals and
make clean API are more than welcome. Thank you!
--
Vitaly
next prev parent reply other threads:[~2018-03-05 10:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-02 10:55 [PATCH RFC 0/3] x86/kvm: avoid expensive rdmsrs for FS/GS base MSRs Vitaly Kuznetsov
2018-03-02 10:55 ` [PATCH RFC 1/3] x86/kvm/vmx: read MSR_FS_BASE from current->thread Vitaly Kuznetsov
2018-03-02 20:18 ` Andy Lutomirski
2018-03-05 9:56 ` Vitaly Kuznetsov
2018-03-07 13:15 ` Vitaly Kuznetsov
2018-03-02 10:55 ` [PATCH RFC 2/3] x86/kvm/vmx: read MSR_KERNEL_GS_BASE " Vitaly Kuznetsov
2018-03-02 10:55 ` [PATCH RFC 3/3] x86/kvm/vmx: avoid expensive rdmsr for MSR_GS_BASE Vitaly Kuznetsov
2018-03-02 20:20 ` Andy Lutomirski
2018-03-05 10:04 ` Vitaly Kuznetsov [this message]
2018-03-06 10:16 ` [PATCH RFC 0/3] x86/kvm: avoid expensive rdmsrs for FS/GS base MSRs Paolo Bonzini
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=87zi3mzvmz.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox