I don't see any reason for them for not be available, especially
since core2_vpmu_do_wrmsr has PV specific logic for MSR_IA32_DS_AREA.
Fixes: 27c554198666 ("x86/VPMU: add support for PMU register handling on PV guests")
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
---
xen/arch/x86/pv/emul-priv-op.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index b2556f9213..0d93218030 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -993,6 +993,8 @@ static int cf_check read_msr(
case MSR_P6_EVNTSEL(0) ... MSR_P6_EVNTSEL(7):
case MSR_CORE_PERF_FIXED_CTR0 ... MSR_CORE_PERF_FIXED_CTR2:
case MSR_CORE_PERF_FIXED_CTR_CTRL ... MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+ case MSR_IA32_PEBS_ENABLE:
+ case MSR_IA32_DS_AREA:
if ( boot_cpu_data.vendor == X86_VENDOR_INTEL )
{
vpmu_msr = true;
@@ -1170,6 +1172,8 @@ static int cf_check write_msr(
case MSR_P6_EVNTSEL(0) ... MSR_P6_EVNTSEL(7):
case MSR_CORE_PERF_FIXED_CTR0 ... MSR_CORE_PERF_FIXED_CTR2:
case MSR_CORE_PERF_FIXED_CTR_CTRL ... MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+ case MSR_IA32_PEBS_ENABLE:
+ case MSR_IA32_DS_AREA:
if ( boot_cpu_data.vendor == X86_VENDOR_INTEL )
{
vpmu_msr = true;
--
2.53.0
--
Teddy Astie | Vates XCP-ng Developer
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.tech
On 10.03.2026 17:44, Teddy Astie wrote:
> I don't see any reason for them for not be available, especially
> since core2_vpmu_do_wrmsr has PV specific logic for MSR_IA32_DS_AREA.
This is really dangerous: You allow PV domains to control whether the area
is actually mapped. It lacking a mapping can, iirc, on at least some CPUs
result in a complete hang. I do, in fact, have been carrying a patch to
completely disallow DS area use for PV, eliminating the misleading code
you refer to.
Also note that VPMU_CPU_HAS_DS cannot be set for PV vCPU-s anyway.
> Fixes: 27c554198666 ("x86/VPMU: add support for PMU register handling on PV guests")
Not just because of the above, I'm pretty sure a Fixes: tag is inappropriate
here.
Jan
Le 24/03/2026 à 10:14, Jan Beulich a écrit :
> On 10.03.2026 17:44, Teddy Astie wrote:
>> I don't see any reason for them for not be available, especially
>> since core2_vpmu_do_wrmsr has PV specific logic for MSR_IA32_DS_AREA.
>
> This is really dangerous: You allow PV domains to control whether the area
> is actually mapped. It lacking a mapping can, iirc, on at least some CPUs
> result in a complete hang. I do, in fact, have been carrying a patch to
> completely disallow DS area use for PV, eliminating the misleading code
> you refer to.
>
While PV case is particularly quirky (especially with L1TF), the issues
still exists for HVM.
I suppose things may be a bit better with "EPT-Friendly PEBS" though.
Regardless, we already say that the feature is potentially unsafe to
use, and it still needs to be opted-in, so this patch just allows the
guest to use something we advertise (with its eventual quirks).
> Also note that VPMU_CPU_HAS_DS cannot be set for PV vCPU-s anyway.
>
Why is that ?
`vpmu_set(vpmu, VPMU_CPU_HAS_DS);` made in core2_vpmu_initialise is
called in either PV and HVM cases.
>> Fixes: 27c554198666 ("x86/VPMU: add support for PMU register handling on PV guests")
>
> Not just because of the above, I'm pretty sure a Fixes: tag is inappropriate
> here.
>
> Jan
>
Teddy
--
Teddy Astie | Vates XCP-ng Developer
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.tech
On 25.03.2026 11:16, Teddy Astie wrote: > Le 24/03/2026 à 10:14, Jan Beulich a écrit : >> On 10.03.2026 17:44, Teddy Astie wrote: >>> I don't see any reason for them for not be available, especially >>> since core2_vpmu_do_wrmsr has PV specific logic for MSR_IA32_DS_AREA. >> >> This is really dangerous: You allow PV domains to control whether the area >> is actually mapped. It lacking a mapping can, iirc, on at least some CPUs >> result in a complete hang. I do, in fact, have been carrying a patch to >> completely disallow DS area use for PV, eliminating the misleading code >> you refer to. >> > > While PV case is particularly quirky (especially with L1TF), the issues > still exists for HVM. > I suppose things may be a bit better with "EPT-Friendly PEBS" though. > > Regardless, we already say that the feature is potentially unsafe to > use, and it still needs to be opted-in, so this patch just allows the > guest to use something we advertise (with its eventual quirks). > >> Also note that VPMU_CPU_HAS_DS cannot be set for PV vCPU-s anyway. >> > > Why is that ? > > `vpmu_set(vpmu, VPMU_CPU_HAS_DS);` made in core2_vpmu_initialise is > called in either PV and HVM cases. Oh, I'm sorry, that's yet again a result of aforementioned patch. Jan
On 24/03/2026 9:11 am, Jan Beulich wrote: > On 10.03.2026 17:44, Teddy Astie wrote: >> I don't see any reason for them for not be available, especially >> since core2_vpmu_do_wrmsr has PV specific logic for MSR_IA32_DS_AREA. > This is really dangerous: You allow PV domains to control whether the area > is actually mapped. It lacking a mapping can, iirc, on at least some CPUs > result in a complete hang. It's ~all, and explicitly documented. SDM Vol3 20.4.9.3: "The recording of branch records in the BTS buffer (or PEBS records in the PEBS buffer) may not operate properly if accesses to the linear addresses in any of the three DS save area sections cause page faults, VM exits, or the setting of accessed or dirty flags in the paging structures (ordinary or EPT). For that reason, system software should establish paging structures (both ordinary and EPT) to prevent such occurrences." There are potentially uses for PEBS/DS, but it needs to be via explicit opt in only; it is absolutely not safe to let guests have in general. One fun interaction would be a PV domain which gets shadowed (PV-L1TF, or migrated), which will instantly violate the #PF requirement. ~Andrew
On 24.03.2026 11:42, Andrew Cooper wrote: > On 24/03/2026 9:11 am, Jan Beulich wrote: >> On 10.03.2026 17:44, Teddy Astie wrote: >>> I don't see any reason for them for not be available, especially >>> since core2_vpmu_do_wrmsr has PV specific logic for MSR_IA32_DS_AREA. >> This is really dangerous: You allow PV domains to control whether the area >> is actually mapped. It lacking a mapping can, iirc, on at least some CPUs >> result in a complete hang. > > It's ~all, and explicitly documented. SDM Vol3 20.4.9.3: > > "The recording of branch records in the BTS buffer (or PEBS records in > the PEBS buffer) may not operate properly if accesses to the linear > addresses in any of the three DS save area sections cause page faults, > VM exits, or the setting of accessed or dirty flags in the paging > structures (ordinary or EPT). For that reason, system software should > establish paging structures (both ordinary and EPT) to prevent such > occurrences." > > There are potentially uses for PEBS/DS, but it needs to be via explicit > opt in only; it is absolutely not safe to let guests have in general. That would extend to HVM as well then, wouldn't it? > One fun interaction would be a PV domain which gets shadowed (PV-L1TF, > or migrated), which will instantly violate the #PF requirement. Same here, just with EPT misconfig exits in place of #PF? Jan
On 24/03/2026 11:10 am, Jan Beulich wrote: > On 24.03.2026 11:42, Andrew Cooper wrote: >> On 24/03/2026 9:11 am, Jan Beulich wrote: >>> On 10.03.2026 17:44, Teddy Astie wrote: >>>> I don't see any reason for them for not be available, especially >>>> since core2_vpmu_do_wrmsr has PV specific logic for MSR_IA32_DS_AREA. >>> This is really dangerous: You allow PV domains to control whether the area >>> is actually mapped. It lacking a mapping can, iirc, on at least some CPUs >>> result in a complete hang. >> It's ~all, and explicitly documented. SDM Vol3 20.4.9.3: >> >> "The recording of branch records in the BTS buffer (or PEBS records in >> the PEBS buffer) may not operate properly if accesses to the linear >> addresses in any of the three DS save area sections cause page faults, >> VM exits, or the setting of accessed or dirty flags in the paging >> structures (ordinary or EPT). For that reason, system software should >> establish paging structures (both ordinary and EPT) to prevent such >> occurrences." >> >> There are potentially uses for PEBS/DS, but it needs to be via explicit >> opt in only; it is absolutely not safe to let guests have in general. > That would extend to HVM as well then, wouldn't it? > >> One fun interaction would be a PV domain which gets shadowed (PV-L1TF, >> or migrated), which will instantly violate the #PF requirement. > Same here, just with EPT misconfig exits in place of #PF? Yes it does extend to HVM guests too. The difference is that it already exists for HVM guests, via the vpmu=dts option. ~Andrew
© 2016 - 2026 Red Hat, Inc.