| Message ID | 20220718140517.14771-1-jandryuk@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86: Add MMIO Stale Data arch_caps to hardware domain | expand |
On 18.07.2022 16:05, Jason Andryuk wrote: > Let the hardware domain know about the hardware it is running on. This > allows a linux Dom0 to know that it has the appropriate microcode via > FB_CLEAR. /sys/devices/system/cpu/vulnerabilities/mmio_stale_data > changes from: > "Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state > unknown" > to: > "Mitigation: Clear CPU buffers; SMT Host state unknown" > > Signed-off-by: Jason Andryuk <jandryuk@gmail.com> > --- > Should calculate_host_policy()'s arch_caps mask also be updated? They > are not identical today, but I'm don't know this code to understand why > they differ. I think this wants updating too, yes. I'm afraid I have to leave it to Andrew to provide the reasons for the differences between the two. I would further suggest to also consider adding RRSBA and BHI_NO, even if then the title would want adjusting. And finally I'd like to ask to add a proper Fixes: tag (or more), as it looks like the updating here was simply forgotten when the bits were introduced. Ideally we'd have a way for the compiler to remind us of updates being needed (or at least be considered) here. Jan
On Mon, Jul 18, 2022 at 10:18 AM Jan Beulich <jbeulich@suse.com> wrote: > > On 18.07.2022 16:05, Jason Andryuk wrote: > > Let the hardware domain know about the hardware it is running on. This > > allows a linux Dom0 to know that it has the appropriate microcode via > > FB_CLEAR. /sys/devices/system/cpu/vulnerabilities/mmio_stale_data > > changes from: > > "Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state > > unknown" > > to: > > "Mitigation: Clear CPU buffers; SMT Host state unknown" > > > > Signed-off-by: Jason Andryuk <jandryuk@gmail.com> > > --- > > Should calculate_host_policy()'s arch_caps mask also be updated? They > > are not identical today, but I'm don't know this code to understand why > > they differ. > > I think this wants updating too, yes. I'm afraid I have to leave it to > Andrew to provide the reasons for the differences between the two. > > I would further suggest to also consider adding RRSBA and BHI_NO, even > if then the title would want adjusting. And finally I'd like to ask to > add a proper Fixes: tag (or more), as it looks like the updating here > was simply forgotten when the bits were introduced. Ideally we'd have > a way for the compiler to remind us of updates being needed (or at > least be considered) here. That all sounds good. Thanks, Jason
On 18/07/2022 15:34, Jason Andryuk wrote: > On Mon, Jul 18, 2022 at 10:18 AM Jan Beulich <jbeulich@suse.com> wrote: >> On 18.07.2022 16:05, Jason Andryuk wrote: >>> Let the hardware domain know about the hardware it is running on. This >>> allows a linux Dom0 to know that it has the appropriate microcode via >>> FB_CLEAR. /sys/devices/system/cpu/vulnerabilities/mmio_stale_data >>> changes from: >>> "Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state >>> unknown" >>> to: >>> "Mitigation: Clear CPU buffers; SMT Host state unknown" >>> >>> Signed-off-by: Jason Andryuk <jandryuk@gmail.com> >>> --- >>> Should calculate_host_policy()'s arch_caps mask also be updated? They >>> are not identical today, but I'm don't know this code to understand why >>> they differ. >> I think this wants updating too, yes. I'm afraid I have to leave it to >> Andrew to provide the reasons for the differences between the two. >> >> I would further suggest to also consider adding RRSBA and BHI_NO, even >> if then the title would want adjusting. And finally I'd like to ask to >> add a proper Fixes: tag (or more), as it looks like the updating here >> was simply forgotten when the bits were introduced. Ideally we'd have >> a way for the compiler to remind us of updates being needed (or at >> least be considered) here. > That all sounds good. This is all one giant hack because of the fact we don't virtualise MSR_ARCH_CAPS properly for guests yet. Furthermore, Linux's sysfs files are largely nonsense in a PV guest. "SMT=unknown" is a good example, but others need help too. The calculate_host_policy() list does want updating. That's my fault for forgetting; it's the first MSR "feature leaf" and none of this is calculated automatically. The raw and host values are exactly as per CPUID. raw = real CPU values, host = subset that Xen understands. In reality, there's a lot of hardware where model checks should cause us to synthesize bits in the host policy which are missing in raw, but doing that nicely still depends on untangling microcode loading from xmalloc() so we can sort things out much earlier. I agree with Jan that dom0 should see RRSBA and BHI_NO. The former should be enumerated from ADL/SPR whereas I have no idea when BHI_NO might land. ~Andrew
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c index c2c0025e3a..f1c36d423f 100644 --- a/xen/arch/x86/msr.c +++ b/xen/arch/x86/msr.c @@ -163,7 +163,9 @@ int init_domain_msr_policy(struct domain *d) mp->arch_caps.raw = val & (ARCH_CAPS_RDCL_NO | ARCH_CAPS_IBRS_ALL | ARCH_CAPS_RSBA | - ARCH_CAPS_SSB_NO | ARCH_CAPS_MDS_NO | ARCH_CAPS_TAA_NO); + ARCH_CAPS_SSB_NO | ARCH_CAPS_MDS_NO | ARCH_CAPS_TAA_NO | + ARCH_CAPS_SBDR_SSDP_NO | ARCH_CAPS_FBSDP_NO | ARCH_CAPS_PSDP_NO | + ARCH_CAPS_FB_CLEAR); } d->arch.msr = mp;
Let the hardware domain know about the hardware it is running on. This allows a linux Dom0 to know that it has the appropriate microcode via FB_CLEAR. /sys/devices/system/cpu/vulnerabilities/mmio_stale_data changes from: "Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown" to: "Mitigation: Clear CPU buffers; SMT Host state unknown" Signed-off-by: Jason Andryuk <jandryuk@gmail.com> --- Should calculate_host_policy()'s arch_caps mask also be updated? They are not identical today, but I'm don't know this code to understand why they differ. xen/arch/x86/msr.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)