Instead of always doing the safe variants for reading and writing MSRs
in Xen PV guests, make the behavior controllable via Kconfig option
and a boot parameter.
The default will be the current behavior, which is to always use the
safe variant.
Signed-off-by: Juergen Gross <[email protected]>
---
.../admin-guide/kernel-parameters.txt | 6 +++++
arch/x86/xen/Kconfig | 9 +++++++
arch/x86/xen/enlighten_pv.c | 24 +++++++++++--------
3 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 426fa892d311..1bda9cf18fae 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -6836,6 +6836,12 @@
Crash from Xen panic notifier, without executing late
panic() code such as dumping handler.
+ xen_msr_safe= [X86,XEN]
+ Format: <bool>
+ Select whether to always use non-faulting (safe) MSR
+ access functions when running as Xen PV guest. The
+ default value is controlled by CONFIG_XEN_PV_MSR_SAFE.
+
xen_nopvspin [X86,XEN]
Disables the qspinlock slowpath using Xen PV optimizations.
This parameter is obsoleted by "nopvspin" parameter, which
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 85246dd9faa1..9b1ec5d8c99c 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -92,3 +92,12 @@ config XEN_DOM0
select X86_X2APIC if XEN_PVH && X86_64
help
Support running as a Xen Dom0 guest.
+
+config XEN_PV_MSR_SAFE
+ bool "Always use safe MSR accesses in PV guests"
+ default y
+ depends on XEN_PV
+ help
+ Use safe (not faulting) MSR access functions even if the MSR access
+ should not fault anyway.
+ The default can be changed by using the "xen_msr_safe" boot parameter.
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4e68e047df94..6b0e5d4c485a 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -108,6 +108,16 @@ struct tls_descs {
*/
static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
+static __read_mostly bool xen_msr_safe = IS_ENABLED(CONFIG_XEN_PV_MSR_SAFE);
+
+static int __init parse_xen_msr_safe(char *str)
+{
+ if (str)
+ return strtobool(str, &xen_msr_safe);
+ return -EINVAL;
+}
+early_param("xen_msr_safe", parse_xen_msr_safe);
+
static void __init xen_pv_init_platform(void)
{
/* PV guests can't operate virtio devices without grants. */
@@ -1010,22 +1020,16 @@ static int xen_write_msr_safe(unsigned int msr, unsigned int low,
static u64 xen_read_msr(unsigned int msr)
{
- /*
- * This will silently swallow a #GP from RDMSR. It may be worth
- * changing that.
- */
int err;
- return xen_read_msr_safe(msr, &err);
+ return xen_do_read_msr(msr, xen_msr_safe ? &err : NULL);
}
static void xen_write_msr(unsigned int msr, unsigned low, unsigned high)
{
- /*
- * This will silently swallow a #GP from WRMSR. It may be worth
- * changing that.
- */
- xen_write_msr_safe(msr, low, high);
+ int err;
+
+ xen_do_write_msr(msr, low, high, xen_msr_safe ? &err : NULL);
}
/* This is called once we have the cpu_possible_mask */
--
2.35.3
On 26.09.22 17:23, Jan Beulich wrote:
> On 26.09.2022 16:18, Juergen Gross wrote:
>> --- a/arch/x86/xen/Kconfig
>> +++ b/arch/x86/xen/Kconfig
>> @@ -92,3 +92,12 @@ config XEN_DOM0
>> select X86_X2APIC if XEN_PVH && X86_64
>> help
>> Support running as a Xen Dom0 guest.
>> +
>> +config XEN_PV_MSR_SAFE
>> + bool "Always use safe MSR accesses in PV guests"
>> + default y
>
> Is there any time line when this default will change, perhaps first to
> DEBUG and later to N?
I'm not sure. I did an initial test with the safe variants disabled in dom0
and it just worked.
I'm not sure we want an intermediate step, as in critical cases the user can
still use the boot parameter.
>
>> @@ -1010,22 +1020,16 @@ static int xen_write_msr_safe(unsigned int msr, unsigned int low,
>>
>> static u64 xen_read_msr(unsigned int msr)
>> {
>> - /*
>> - * This will silently swallow a #GP from RDMSR. It may be worth
>> - * changing that.
>> - */
>> int err;
>>
>> - return xen_read_msr_safe(msr, &err);
>> + return xen_do_read_msr(msr, xen_msr_safe ? &err : NULL);
>> }
>
> When we were talking at the session, I think I said that at least there
> is no uninitialized value being passed back. But I did look at
> xen_read_msr_safe() only, which indeed is okay. Whereas
> native_read_msr_safe() isn't (nor is native_read_msr() afaict), so I
> think part of this series should be to also eliminate the undefined-
> ness from this code path (possible now only when xen_msr_safe is true,
> but as per above that'll be the default at least for some time), where
> the caller has no way to know that it shouldn't look at the value.
I can add that.
Juergen
On 26.09.2022 16:18, Juergen Gross wrote:
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -92,3 +92,12 @@ config XEN_DOM0
> select X86_X2APIC if XEN_PVH && X86_64
> help
> Support running as a Xen Dom0 guest.
> +
> +config XEN_PV_MSR_SAFE
> + bool "Always use safe MSR accesses in PV guests"
> + default y
Is there any time line when this default will change, perhaps first to
DEBUG and later to N?
> @@ -1010,22 +1020,16 @@ static int xen_write_msr_safe(unsigned int msr, unsigned int low,
>
> static u64 xen_read_msr(unsigned int msr)
> {
> - /*
> - * This will silently swallow a #GP from RDMSR. It may be worth
> - * changing that.
> - */
> int err;
>
> - return xen_read_msr_safe(msr, &err);
> + return xen_do_read_msr(msr, xen_msr_safe ? &err : NULL);
> }
When we were talking at the session, I think I said that at least there
is no uninitialized value being passed back. But I did look at
xen_read_msr_safe() only, which indeed is okay. Whereas
native_read_msr_safe() isn't (nor is native_read_msr() afaict), so I
think part of this series should be to also eliminate the undefined-
ness from this code path (possible now only when xen_msr_safe is true,
but as per above that'll be the default at least for some time), where
the caller has no way to know that it shouldn't look at the value.
Jan