From: "Liu, Jing2" <jing2.liu@linux.intel.com>
To: "Bae, Chang Seok" <chang.seok.bae@intel.com>,
"Liu, Jing2" <jing2.liu@intel.com>
Cc: "bp@suse.de" <bp@suse.de>, "luto@kernel.org" <luto@kernel.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@kernel.org" <mingo@kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"Brown, Len" <len.brown@intel.com>,
"Hansen, Dave" <dave.hansen@intel.com>,
"Shankar, Ravi V" <ravi.v.shankar@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH v3 10/21] x86/fpu/xstate: Update xstate save function to support dynamic xstate
Date: Tue, 12 Jan 2021 10:52:29 +0800 [thread overview]
Message-ID: <0361132a-c088-331b-de1f-e0de23d729ab@linux.intel.com> (raw)
In-Reply-To: <29CB32F5-1E73-46D4-BF92-18AD05F53E8E@intel.com>
On 1/8/2021 2:40 AM, Bae, Chang Seok wrote:
>> On Jan 7, 2021, at 17:41, Liu, Jing2 <jing2.liu@intel.com> wrote:
>>
>> static void kvm_save_current_fpu(struct fpu *fpu) {
>> + struct fpu *src_fpu = ¤t->thread.fpu;
>> +
>> /*
>> * If the target FPU state is not resident in the CPU registers, just
>> * memcpy() from current, else save CPU state directly to the target.
>> */
>> - if (test_thread_flag(TIF_NEED_FPU_LOAD))
>> - memcpy(&fpu->state, ¤t->thread.fpu.state,
>> + if (test_thread_flag(TIF_NEED_FPU_LOAD)) {
>> + memcpy(&fpu->state, &src_fpu->state,
>> fpu_kernel_xstate_min_size);
>> For kvm, if we assume that it does not support dynamic features until this series,
>> memcpy for only fpu->state is correct.
>> I think this kind of assumption is reasonable and we only make original xstate work.
>>
>> - else
>> + } else {
>> + if (fpu->state_mask != src_fpu->state_mask)
>> + fpu->state_mask = src_fpu->state_mask;
>>
>> Though dynamic feature is not supported in kvm now, this function still need
>> consider more things for fpu->state_mask.
> Can you elaborate this? Which path might be affected by fpu->state_mask
> without dynamic state supported in KVM?
>
>> I suggest that we can set it before if...else (for both cases) and not change other.
> I tried a minimum change here. The fpu->state_mask value does not impact the
> memcpy(). So, why do we need to change it for both?
Sure, what I'm considering is that "mask" is the first time introduced
into "fpu",
representing the usage, so not only set it when needed, but also make it
as a
representation, in case of anywhere using it (especially between the
interval
of this series and kvm series in future).
Thanks,
Jing
> Thanks,
> Chang
next prev parent reply other threads:[~2021-01-12 2:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20201223155717.19556-1-chang.seok.bae@intel.com>
2020-12-23 15:56 ` [PATCH v3 01/21] x86/fpu/xstate: Modify initialization helper to handle both static and dynamic buffers Chang S. Bae
2021-01-15 12:40 ` Borislav Petkov
2020-12-23 15:56 ` [PATCH v3 03/21] x86/fpu/xstate: Modify address finders " Chang S. Bae
2021-01-15 13:06 ` Borislav Petkov
2020-12-23 15:57 ` [PATCH v3 04/21] x86/fpu/xstate: Modify context switch helpers " Chang S. Bae
2021-01-15 13:18 ` Borislav Petkov
2021-01-19 18:49 ` Bae, Chang Seok
2020-12-23 15:57 ` [PATCH v3 06/21] x86/fpu/xstate: Calculate and remember dynamic xstate buffer sizes Chang S. Bae
2021-01-22 11:44 ` Borislav Petkov
2021-01-27 1:23 ` Bae, Chang Seok
2021-01-27 9:38 ` Borislav Petkov
2021-02-03 2:54 ` Bae, Chang Seok
2020-12-23 15:57 ` [PATCH v3 10/21] x86/fpu/xstate: Update xstate save function to support dynamic xstate Chang S. Bae
2021-01-07 8:41 ` Liu, Jing2
2021-01-07 18:40 ` Bae, Chang Seok
2021-01-12 2:52 ` Liu, Jing2 [this message]
2021-01-15 4:59 ` Bae, Chang Seok
2021-01-15 5:45 ` Liu, Jing2
2021-02-08 12:33 ` Borislav Petkov
2021-02-09 15:48 ` Bae, Chang Seok
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=0361132a-c088-331b-de1f-e0de23d729ab@linux.intel.com \
--to=jing2.liu@linux.intel.com \
--cc=bp@suse.de \
--cc=chang.seok.bae@intel.com \
--cc=dave.hansen@intel.com \
--cc=jing2.liu@intel.com \
--cc=kvm@vger.kernel.org \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=ravi.v.shankar@intel.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).