From: "Liu, Jing2" <jing2.liu@linux.intel.com>
To: Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>
Cc: Yang Zhong <yang.zhong@intel.com>,
Paolo Bonzini <pbonzini@redhat.com>,
x86@kernel.org, kvm@vger.kernel.org,
Sean Christoperson <seanjc@google.com>,
Jin Nakajima <jun.nakajima@intel.com>,
Kevin Tian <kevin.tian@intel.com>
Subject: Re: [patch 0/6] x86/fpu: Preparatory changes for guest AMX support
Date: Tue, 14 Dec 2021 14:52:18 +0800 [thread overview]
Message-ID: <12b5a1e8-89ae-1c56-9568-d774a5016548@linux.intel.com> (raw)
In-Reply-To: <20211214022825.563892248@linutronix.de>
Hi Thomas,
On 12/14/2021 10:50 AM, Thomas Gleixner wrote:
> Folks,
>
> this is a follow up to the initial sketch of patches which got picked up by
> Jing and have been posted in combination with the KVM parts:
>
> https://lore.kernel.org/r/20211208000359.2853257-1-yang.zhong@intel.com
>
> This update is only touching the x86/fpu code and not changing anything on
> the KVM side.
>
> BIG FAT WARNING: This is compile tested only!
>
> In course of the dicsussion of the above patchset it turned out that there
> are a few conceptual issues vs. hardware and software state and also
> vs. guest restore.
>
> This series addresses this with the following changes vs. the original
> approach:
>
> 1) fpstate reallocation is now independent of fpu_swap_kvm_fpstate()
>
> It is triggered directly via XSETBV and XFD MSR write emulation which
> are used both for runtime and restore purposes.
>
> For this it provides two wrappers around a common update function, one
> for XCR0 and one for XFD.
>
> Both check the validity of the arguments and the correct sizing of the
> guest FPU fpstate. If the size is not sufficient, fpstate is
> reallocated.
>
> The functions can fail.
>
> 2) XFD synchronization
>
> KVM must neither touch the XFD MSR nor the fpstate->xfd software state
> in order to guarantee state consistency.
>
> In the MSR write emulation case the XFD specific update handler has to
> be invoked. See #1
>
> If MSR write emulation is disabled because the buffer size is
> sufficient for all use cases, i.e.:
>
> guest_fpu::xfeatures == guest_fpu::perm
>
The buffer size can be sufficient once one of the features is requested
since
kernel fpu realloc full size (permitted). And I think we don't want to
disable
interception until all the features are detected e.g., one by one.
Thus it can be guest_fpu::xfeatures != guest_fpu::perm.
Thanks,
Jing
next prev parent reply other threads:[~2021-12-14 6:53 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-14 2:50 Thomas Gleixner
2021-12-14 2:50 ` [patch 1/6] x86/fpu: Extend fpu_xstate_prctl() with guest permissions Thomas Gleixner
2021-12-14 5:13 ` Tian, Kevin
2021-12-14 10:37 ` Paolo Bonzini
2021-12-14 2:50 ` [patch 2/6] x86/fpu: Prepare guest FPU for dynamically enabled FPU features Thomas Gleixner
2021-12-14 2:50 ` [patch 3/6] x86/fpu: Make XFD initialization in __fpstate_reset() a function argument Thomas Gleixner
2021-12-14 2:50 ` [patch 4/6] x86/fpu: Add guest support to xfd_enable_feature() Thomas Gleixner
2021-12-14 6:05 ` Tian, Kevin
2021-12-14 10:21 ` Paolo Bonzini
2021-12-14 13:15 ` Thomas Gleixner
2021-12-15 5:46 ` Tian, Kevin
2021-12-15 9:53 ` Thomas Gleixner
2021-12-15 10:02 ` Tian, Kevin
2021-12-14 2:50 ` [patch 5/6] x86/fpu: Provide fpu_update_guest_xcr0/xfd() Thomas Gleixner
2021-12-14 6:25 ` Tian, Kevin
2021-12-14 15:09 ` Wang, Wei W
2021-12-14 15:40 ` Thomas Gleixner
2021-12-14 16:11 ` Wang, Wei W
2021-12-14 18:04 ` Thomas Gleixner
2021-12-14 19:07 ` Juan Quintela
2021-12-14 20:28 ` Thomas Gleixner
2021-12-14 21:35 ` Juan Quintela
2021-12-15 2:17 ` Wang, Wei W
2021-12-15 10:09 ` Thomas Gleixner
2021-12-15 10:27 ` Paolo Bonzini
2021-12-15 10:41 ` Paolo Bonzini
2021-12-16 1:00 ` Tian, Kevin
2021-12-16 5:36 ` Tian, Kevin
2021-12-16 21:07 ` Paolo Bonzini
2021-12-16 10:21 ` Tian, Kevin
2021-12-16 10:24 ` Paolo Bonzini
2021-12-16 10:26 ` Paolo Bonzini
2021-12-16 13:00 ` Tian, Kevin
2021-12-16 1:04 ` Tian, Kevin
2021-12-16 9:34 ` Thomas Gleixner
2021-12-16 9:59 ` Tian, Kevin
2021-12-16 14:12 ` Thomas Gleixner
2021-12-17 15:33 ` Tian, Kevin
2021-12-15 6:14 ` Tian, Kevin
2021-12-14 2:50 ` [patch 6/6] x86/fpu: Provide kvm_sync_guest_vmexit_xfd_state() Thomas Gleixner
2021-12-15 6:35 ` Liu, Jing2
2021-12-15 9:49 ` Thomas Gleixner
2021-12-14 6:50 ` [patch 0/6] x86/fpu: Preparatory changes for guest AMX support Tian, Kevin
2021-12-14 6:52 ` Liu, Jing2 [this message]
2021-12-14 7:54 ` Tian, Kevin
2021-12-14 10:42 ` Paolo Bonzini
2021-12-14 13:24 ` Thomas Gleixner
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=12b5a1e8-89ae-1c56-9568-d774a5016548@linux.intel.com \
--to=jing2.liu@linux.intel.com \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yang.zhong@intel.com \
/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
all inboxes | Powered by JetHome®