From: Paolo Bonzini <pbonzini@redhat.com>
To: Nick Desaulniers <nick.desaulniers@gmail.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: dynamically allocate large struct in em_fxrstor
Date: Fri, 26 May 2017 09:18:12 +0200 [thread overview]
Message-ID: <a2b87472-7b3b-71b4-3d6b-2eb7987b6eaa@redhat.com> (raw)
In-Reply-To: <20170526041327.ttnlnwyuv4bbxdxx@lostoracle.net>
On 26/05/2017 06:13, Nick Desaulniers wrote:
> On Thu, May 25, 2017 at 04:07:08PM +0200, Paolo Bonzini wrote:
>> I think we should do the fixup backwards.
>>
>> That is:
>>
>> - first do get_fpu
>>
>> - if the fixup is necessary, i.e. ctxt->mode < X86EMUL_MODE_PROT64, do
>> fxsave into &fxstate.
>>
>> - then do segmented_read_std with the correct size, which is
>> - offsetof(struct fxregs_state, xmm_space[16]), i.e. 416
>> if ctxt->mode == X86EMUL_MODE_PROT64
>> - offsetof(struct fxregs_state, xmm_space[8]), i.e. 288
>> if ctxt->mode < X86EMUL_MODE_PROT64 and CR4.OSFXSR=1
>> - offsetof(struct fxregs_state, xmm_space[0]), i.e. 160
>> if ctxt->mode < X86EMUL_MODE_PROT64 and CR4.OSFXSR=0
>
> but we still want to do a segmented_read_std with size 512 otherwise,
> correct?
No, 512 is never necessary. ctxt->mode is never > X86EMUL_MODE_PROT64
(see the definition of enum x86emul_mode in
arch/x86/include/asm/kvm_emulate.h.
>> - then check fx_state.mxcsr
>>
>> - then do fxrstor
>
> This sounds like we conditionally do the fxsave, but then always do the
> fxrstor. Is that ok? I guess the original code kind of does that as
> well.
Correct. They idea is that fxrstor on Linux always accesses 416 bytes,
but we may have to restore only the first part for accurate emulation.
The fxsave retrieves the current state so that we can leave it
unmodified when we do fxrstor.
>> - finally do put_fpu
>
> Sounds straight forward. I can see how fxsave and CR4.OSFXSR are
> accessed in fxstor_fixup. Is it ok to skip those memcpy's that would
> otherwise occur when calling fxrstor_fixup() (which after these changes,
> we would not be)?
Yes, the memcpys are replaced with a shorter segmented_read_std.
Thanks,
Paolo
next prev parent reply other threads:[~2017-05-26 7:18 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-24 6:24 [PATCH] KVM: x86: dynamically allocate large struct in em_fxrstor Nick Desaulniers
2017-05-24 14:19 ` Radim Krčmář
2017-05-25 1:36 ` Nick Desaulniers
2017-05-25 14:07 ` Paolo Bonzini
2017-05-26 4:13 ` Nick Desaulniers
2017-05-26 7:18 ` Paolo Bonzini [this message]
2017-05-29 19:55 ` [PATCH v2] KVM: x86: avoid large stack allocations " Nick Desaulniers
2017-05-29 20:14 ` kbuild test robot
2017-05-29 20:29 ` Nick Desaulniers
2017-05-29 20:39 ` [PATCH v3] " Nick Desaulniers
2017-05-29 22:40 ` Nick Desaulniers
2017-05-29 22:48 ` [PATCH v4] " Nick Desaulniers
2017-05-30 10:15 ` Paolo Bonzini
2017-05-30 14:05 ` Radim Krčmář
2017-05-31 3:08 ` [PATCH v5] " Nick Desaulniers
2017-05-31 11:01 ` Paolo Bonzini
2017-06-01 1:05 ` Nick Desaulniers
2017-06-01 7:36 ` Paolo Bonzini
2017-06-02 2:10 ` Nick Desaulniers
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=a2b87472-7b3b-71b4-3d6b-2eb7987b6eaa@redhat.com \
--to=pbonzini@redhat.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nick.desaulniers@gmail.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;
as well as URLs for NNTP newsgroup(s).