Re: [PATCH v2 07/25] KVM: VMX: Set intercept for FRED MSRs
On 9/25/2024 7:12 AM, Sean Christopherson wrote: On Wed, Sep 18, 2024, Xin Li wrote: You mean the following patch set, right? Yep, and presumably the KVM support as well: I assume it's close to KVM upstreaming criteria :) https://lore.kernel.org/all/20240219074733.122080-1-weijiang.y...@intel.com https://lore.kernel.org/kvm/20240531090331.13713-1-weijiang.y...@intel.com/ ... When FRED is advertised to a guest, KVM should allow FRED SSP MSRs accesses through disabling FRED SSP MSRs interception no matter whether supervisor shadow stacks are enabled or not. KVM doesn't necessarily need to disabling MSR interception, e.g. if the expectation is that the guest will rarely/never access the MSRs when CET is unsupported, then we're likely better off going with a trap-and-emulate model. KVM needs to emulate RDMSR and WRMSR no matter what, e.g. in case the guest triggers a WRMSR when KVM is emulating, and so that userspace can get/set MSR values. And this means that yes, FRED virtualization needs to land after CET virtualization, otherwise managing the conflicts/dependencies will be a nightmare. No argument. Thanks! Xin
Re: [PATCH] Documentation/process: maintainer-soc: clarify submitting patches
On 24/09/2024 15:19, Conor Dooley wrote: > On Tue, Sep 24, 2024 at 03:08:31PM +0200, Krzysztof Kozlowski wrote: > >> Most of these submaintainers have their own trees where they stage patches, >> sending pull requests to the main SoC tree. These trees are usually, but >> not >> -always, listed in MAINTAINERS. The main SoC maintainers can be reached via >> the >> -alias s...@kernel.org if there is no platform-specific maintainer, or if >> they >> -are unresponsive. >> +always, listed in MAINTAINERS. > > I probably had some specific case in mind with that original wording. I > presume it still holds true for some smaller platforms, but I cannot > remember the specific case that prompted it. I'll have to see if I can > figure out which platforms they are (if any) and get the tree added. > > Cheers, > Conor. > >> What the SoC tree is not, however, is a location for architecture-specific >> code >> changes. Each architecture has its own maintainers that are responsible for >> architectural details, CPU errata and the like. >> >> +Submitting Patches for Given SoC >> + >> + >> +All usual platform related patches should be sent via SoC submaintainers >> +(platform-specific maintainers. This includes also changes to per-platform >> or >^ this is unclosed. Ack. I have v2 with minor text changes in other places as well. I will send soon. Best regards, Krzysztof
[PATCH v2] Documentation/process: maintainer-soc: clarify submitting patches
Patches for SoCs are expected to be picked up by SoC submaintainers.
The main SoC maintainers should be addressed only in few cases.
Rewrite the section about maintainer handling to document above
expectation.
Signed-off-by: Krzysztof Kozlowski
Cc: Linus Walleij
Cc: Alexandre Belloni
Cc: Will Deacon
Cc: Kevin Hilman
Cc: Palmer Dabbelt
Cc: Geert Uytterhoeven
Cc: Conor Dooley
Cc: Heiko Stübner
---
During our LPC ad-hoc BoF, we discussed improving Maintainer SoC docs
and I think I volunteered to write something. The trouble is that
whatever I won't write in my notes, escapes my memory.
I believe this is what we discussed. Was there anything more to
write/document?
Changes in v2:
1. Fix missing closing ) (Conor).
2. Style changes (in point 3.).
3. Soften note that soc@kernel is not for discussing ("is usually not").
---
Documentation/process/maintainer-soc.rst | 42 +---
1 file changed, 37 insertions(+), 5 deletions(-)
diff --git a/Documentation/process/maintainer-soc.rst
b/Documentation/process/maintainer-soc.rst
index 12637530d68f..fe9d8bcfbd2b 100644
--- a/Documentation/process/maintainer-soc.rst
+++ b/Documentation/process/maintainer-soc.rst
@@ -30,10 +30,13 @@ tree as a dedicated branch covering multiple subsystems.
The main SoC tree is housed on git.kernel.org:
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/
+Maintainers
+---
+
Clearly this is quite a wide range of topics, which no one person, or even
small group of people are capable of maintaining. Instead, the SoC subsystem
-is comprised of many submaintainers, each taking care of individual platforms
-and driver subdirectories.
+is comprised of many submaintainers (platform maintainers), each taking care of
+individual platforms and driver subdirectories.
In this regard, "platform" usually refers to a series of SoCs from a given
vendor, for example, Nvidia's series of Tegra SoCs. Many submaintainers
operate
on a vendor level, responsible for multiple product lines. For several
reasons,
@@ -43,14 +46,43 @@ MAINTAINERS file.
Most of these submaintainers have their own trees where they stage patches,
sending pull requests to the main SoC tree. These trees are usually, but not
-always, listed in MAINTAINERS. The main SoC maintainers can be reached via the
-alias s...@kernel.org if there is no platform-specific maintainer, or if they
-are unresponsive.
+always, listed in MAINTAINERS.
What the SoC tree is not, however, is a location for architecture-specific code
changes. Each architecture has its own maintainers that are responsible for
architectural details, CPU errata and the like.
+Submitting Patches for Given SoC
+
+
+All typical platform related patches should be sent via SoC submaintainers
+(platform-specific maintainers). This includes also changes to per-platform or
+shared defconfigs (scripts/get_maintainer.pl might not provide correct
+addresses in such case).
+
+Submitting Patches to the Main SoC Maintainers
+~~
+
+The main SoC maintainers can be reached via the alias s...@kernel.org only in
+following cases:
+
+1. There are no platform-specific maintainers.
+
+2. Platform-specific maintainers are unresponsive.
+
+3. Introducing a completely new SoC platform. Such new SoC work should be sent
+ first to common mailing lists, pointed out by scripts/get_maintainer.pl, for
+ community review. After positive community review, work should be sent to
+ s...@kernel.org in one patchset containing new arch/foo/Kconfig entry, DTS
+ files, MAINTAINERS file entry and optionally initial drivers with their
+ Devicetree bindings. The MAINTAINERS file entry should list new
+ platform-specific maintainers, who are going to be responsible for handling
+ patches for the platform from now on.
+
+Note that the s...@kernel.org is usually not the place to discuss the patches,
+thus work sent to this address should be already considered as acceptable by
+the community.
+
Information for (new) Submaintainers
--
2.43.0
Re: [PATCH v2 07/25] KVM: VMX: Set intercept for FRED MSRs
On Wed, Sep 18, 2024, Xin Li wrote: > > > MSR_IA32_FRED_SSP0 is an alias of the CET MSR_IA32_PL0_SSP and likely to > > > be used in the same way as FRED RSP0, i.e., host FRED SSP0 _should_ be > > > restored in arch_exit_to_user_mode_prepare(). However as of today Linux > > > has no plan to utilize kernel shadow stack thus no one cares host FRED > > > SSP0 (no?). But lets say anyway it is host's responsibility to manage > > > host FRED SSP0, then KVM only needs to take care of guest FRED SSP0 > > > (just like how KVM should handle guest FRED RSP0) even before the > > > supervisor shadow stack feature is advertised to guest. > > > > Heh, I'm not sure what your question is, or if there even is a question. > > KVM > > needs to context switch FRED SSP0 if FRED is exposed to the guest, but > > presumably > > that will be done through XSAVE state? If that's the long term plan, I > > would > > prefer to focus on merging CET virtualization first, and then land FRED > > virtualization > > on top so that KVM doesn't have to carry intermediate code to deal with the > > aliased > > MSR. > > You mean the following patch set, right? Yep, and presumably the KVM support as well: https://lore.kernel.org/all/20240219074733.122080-1-weijiang.y...@intel.com > https://lore.kernel.org/kvm/20240531090331.13713-1-weijiang.y...@intel.com/ ... > > Ugh, but what happens if a CPU (or the host kernel) supports FRED but not > > CET SS? > > Or is that effectively an illegal combination? > > The FRED Spec says: > > IA32_FRED_SSP1, IA32_FRED_SSP2, and IA32_FRED_SSP3 (MSR indices 1D1H– > 1D3H). Together with the existing MSR IA32_PL0_SSP (MSR index 6A4H), these > are the FRED SSP MSRs. > > The FRED SSP MSRs are supported by any processor that enumerates > CPUID.(EAX=7,ECX=1):EAX.FRED[bit 17] as 1. If such a processor does not > support CET, FRED transitions will not use the MSRs (because shadow stacks > are not enabled), but the MSRs would still be accessible using RDMSR and > WRMSR. > > > So they are independent, just that FRED SSP MSRs are NOT used if > supervisor shadow stacks are not enabled (obviously Qemu can be > configured to not advertise CET but FRED). > > When FRED is advertised to a guest, KVM should allow FRED SSP MSRs > accesses through disabling FRED SSP MSRs interception no matter whether > supervisor shadow stacks are enabled or not. KVM doesn't necessarily need to disabling MSR interception, e.g. if the expectation is that the guest will rarely/never access the MSRs when CET is unsupported, then we're likely better off going with a trap-and-emulate model. KVM needs to emulate RDMSR and WRMSR no matter what, e.g. in case the guest triggers a WRMSR when KVM is emulating, and so that userspace can get/set MSR values. And this means that yes, FRED virtualization needs to land after CET virtualization, otherwise managing the conflicts/dependencies will be a nightmare.
