* [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests
@ 2015-05-04 15:02 Boris Ostrovsky
2015-05-05 13:51 ` Andy Lutomirski
` (3 more replies)
0 siblings, 4 replies; 10+ messages in thread
From: Boris Ostrovsky @ 2015-05-04 15:02 UTC (permalink / raw)
To: konrad.wilk, david.vrabel, hpa, mingo, tglx
Cc: linux-kernel, xen-devel, linux, luto, boris.ostrovsky
Commit 61f01dd941ba ("x86_64, asm: Work around AMD SYSRET SS descriptor
attribute issue") makes AMD processors set SS to __KERNEL_DS in
__switch_to() to deal with cases when SS is NULL.
This breaks Xen PV guests who do not want to load SS with__KERNEL_DS.
Since the problem that the commit is trying to address would have to be
fixed in the hypervisor (if it in fact exists under Xen) there is no
reason to set X86_BUG_SYSRET_SS_ATTRS flag for PV VPCUs here.
This can be easily achieved by adding x86_hyper_xen_hvm.set_cpu_features
op which will clear this flag. (And since this structure is no longer
HVM-specific we should do some renaming).
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
---
v2:
* Adjusted ifdefs to account for !CONFIG_PVHVM case
* Renamed xen_guest_init() back to xen_hvm_guest_init()
arch/x86/include/asm/hypervisor.h | 2 +-
arch/x86/kernel/cpu/hypervisor.c | 4 ++--
arch/x86/xen/enlighten.c | 28 +++++++++++++++++++---------
3 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/arch/x86/include/asm/hypervisor.h b/arch/x86/include/asm/hypervisor.h
index e42f758..055ea99 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -50,7 +50,7 @@ extern const struct hypervisor_x86 *x86_hyper;
/* Recognized hypervisors */
extern const struct hypervisor_x86 x86_hyper_vmware;
extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
-extern const struct hypervisor_x86 x86_hyper_xen_hvm;
+extern const struct hypervisor_x86 x86_hyper_xen;
extern const struct hypervisor_x86 x86_hyper_kvm;
extern void init_hypervisor(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index 36ce402..d820d8e 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -27,8 +27,8 @@
static const __initconst struct hypervisor_x86 * const hypervisors[] =
{
-#ifdef CONFIG_XEN_PVHVM
- &x86_hyper_xen_hvm,
+#ifdef CONFIG_XEN
+ &x86_hyper_xen,
#endif
&x86_hyper_vmware,
&x86_hyper_ms_hyperv,
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 94578ef..ac3427a 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1760,6 +1760,9 @@ static struct notifier_block xen_hvm_cpu_notifier = {
static void __init xen_hvm_guest_init(void)
{
+ if (xen_pv_domain())
+ return;
+
init_hvm_pv_info();
xen_hvm_init_shared_info();
@@ -1775,6 +1778,7 @@ static void __init xen_hvm_guest_init(void)
xen_hvm_init_time_ops();
xen_hvm_init_mmu_ops();
}
+#endif
static bool xen_nopv = false;
static __init int xen_parse_nopv(char *arg)
@@ -1784,14 +1788,11 @@ static __init int xen_parse_nopv(char *arg)
}
early_param("xen_nopv", xen_parse_nopv);
-static uint32_t __init xen_hvm_platform(void)
+static uint32_t __init xen_platform(void)
{
if (xen_nopv)
return 0;
- if (xen_pv_domain())
- return 0;
-
return xen_cpuid_base();
}
@@ -1809,11 +1810,20 @@ bool xen_hvm_need_lapic(void)
}
EXPORT_SYMBOL_GPL(xen_hvm_need_lapic);
-const struct hypervisor_x86 x86_hyper_xen_hvm __refconst = {
- .name = "Xen HVM",
- .detect = xen_hvm_platform,
+static void xen_set_cpu_features(struct cpuinfo_x86 *c)
+{
+ if (xen_pv_domain())
+ clear_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
+}
+
+const struct hypervisor_x86 x86_hyper_xen = {
+ .name = "Xen",
+ .detect = xen_platform,
+#ifdef CONFIG_XEN_PVHVM
.init_platform = xen_hvm_guest_init,
+#endif
.x2apic_available = xen_x2apic_para_available,
+ .set_cpu_features = xen_set_cpu_features,
};
-EXPORT_SYMBOL(x86_hyper_xen_hvm);
-#endif
+EXPORT_SYMBOL(x86_hyper_xen);
+
--
1.9.3
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests
2015-05-04 15:02 [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests Boris Ostrovsky
2015-05-05 13:51 ` Andy Lutomirski
@ 2015-05-05 13:51 ` Andy Lutomirski
2015-05-05 14:21 ` Boris Ostrovsky
2015-05-05 17:25 ` David Vrabel
2015-05-05 17:25 ` David Vrabel
3 siblings, 1 reply; 10+ messages in thread
From: Andy Lutomirski @ 2015-05-05 13:51 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Konrad Rzeszutek Wilk, David Vrabel, H. Peter Anvin, Ingo Molnar,
Thomas Gleixner, linux-kernel, xen-devel, linux
On Mon, May 4, 2015 at 8:02 AM, Boris Ostrovsky
<boris.ostrovsky@oracle.com> wrote:
> Commit 61f01dd941ba ("x86_64, asm: Work around AMD SYSRET SS descriptor
> attribute issue") makes AMD processors set SS to __KERNEL_DS in
> __switch_to() to deal with cases when SS is NULL.
>
> This breaks Xen PV guests who do not want to load SS with__KERNEL_DS.
>
> Since the problem that the commit is trying to address would have to be
> fixed in the hypervisor (if it in fact exists under Xen) there is no
> reason to set X86_BUG_SYSRET_SS_ATTRS flag for PV VPCUs here.
>
> This can be easily achieved by adding x86_hyper_xen_hvm.set_cpu_features
> op which will clear this flag. (And since this structure is no longer
> HVM-specific we should do some renaming).
Looks good to me, but:
> static void __init xen_hvm_guest_init(void)
> {
> + if (xen_pv_domain())
> + return;
> +
How can a platform be "hvm" and "pv"? Is that the PVHVM thing?
> +static void xen_set_cpu_features(struct cpuinfo_x86 *c)
> +{
> + if (xen_pv_domain())
> + clear_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
> +}
I haven't followed all the twists and turns, but, if the guest
platform is such that the guest kernel is really executing SYSRET and
we're on AMD, then we have the sysret_ss_attrs bug. If PVHVM has
xen_pv_domain() returning true but also uses SYSRET for real, then
this looks wrong.
--Andy
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests
2015-05-04 15:02 [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests Boris Ostrovsky
@ 2015-05-05 13:51 ` Andy Lutomirski
2015-05-05 13:51 ` Andy Lutomirski
` (2 subsequent siblings)
3 siblings, 0 replies; 10+ messages in thread
From: Andy Lutomirski @ 2015-05-05 13:51 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: linux-kernel, linux, Ingo Molnar, David Vrabel, H. Peter Anvin,
xen-devel, Thomas Gleixner
On Mon, May 4, 2015 at 8:02 AM, Boris Ostrovsky
<boris.ostrovsky@oracle.com> wrote:
> Commit 61f01dd941ba ("x86_64, asm: Work around AMD SYSRET SS descriptor
> attribute issue") makes AMD processors set SS to __KERNEL_DS in
> __switch_to() to deal with cases when SS is NULL.
>
> This breaks Xen PV guests who do not want to load SS with__KERNEL_DS.
>
> Since the problem that the commit is trying to address would have to be
> fixed in the hypervisor (if it in fact exists under Xen) there is no
> reason to set X86_BUG_SYSRET_SS_ATTRS flag for PV VPCUs here.
>
> This can be easily achieved by adding x86_hyper_xen_hvm.set_cpu_features
> op which will clear this flag. (And since this structure is no longer
> HVM-specific we should do some renaming).
Looks good to me, but:
> static void __init xen_hvm_guest_init(void)
> {
> + if (xen_pv_domain())
> + return;
> +
How can a platform be "hvm" and "pv"? Is that the PVHVM thing?
> +static void xen_set_cpu_features(struct cpuinfo_x86 *c)
> +{
> + if (xen_pv_domain())
> + clear_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
> +}
I haven't followed all the twists and turns, but, if the guest
platform is such that the guest kernel is really executing SYSRET and
we're on AMD, then we have the sysret_ss_attrs bug. If PVHVM has
xen_pv_domain() returning true but also uses SYSRET for real, then
this looks wrong.
--Andy
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests
2015-05-05 13:51 ` Andy Lutomirski
@ 2015-05-05 14:21 ` Boris Ostrovsky
0 siblings, 0 replies; 10+ messages in thread
From: Boris Ostrovsky @ 2015-05-05 14:21 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Konrad Rzeszutek Wilk, David Vrabel, H. Peter Anvin, Ingo Molnar,
Thomas Gleixner, linux-kernel, xen-devel, linux
On 05/05/2015 09:51 AM, Andy Lutomirski wrote:
> On Mon, May 4, 2015 at 8:02 AM, Boris Ostrovsky
> <boris.ostrovsky@oracle.com> wrote:
>> Commit 61f01dd941ba ("x86_64, asm: Work around AMD SYSRET SS descriptor
>> attribute issue") makes AMD processors set SS to __KERNEL_DS in
>> __switch_to() to deal with cases when SS is NULL.
>>
>> This breaks Xen PV guests who do not want to load SS with__KERNEL_DS.
>>
>> Since the problem that the commit is trying to address would have to be
>> fixed in the hypervisor (if it in fact exists under Xen) there is no
>> reason to set X86_BUG_SYSRET_SS_ATTRS flag for PV VPCUs here.
>>
>> This can be easily achieved by adding x86_hyper_xen_hvm.set_cpu_features
>> op which will clear this flag. (And since this structure is no longer
>> HVM-specific we should do some renaming).
> Looks good to me, but:
>
>> static void __init xen_hvm_guest_init(void)
>> {
>> + if (xen_pv_domain())
>> + return;
>> +
> How can a platform be "hvm" and "pv"? Is that the PVHVM thing?
No, this is meant for "true" PV guest not to go through HVM-specific
initialization.
We have to do it since now x86_hyper_xen_hvm (renamed to x86_hyper_xen)
will have init_platform() op and so init_hypervisor_platform() will call
it obviously without knowing the type of the guest.
>
>> +static void xen_set_cpu_features(struct cpuinfo_x86 *c)
>> +{
>> + if (xen_pv_domain())
>> + clear_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
>> +}
> I haven't followed all the twists and turns, but, if the guest
> platform is such that the guest kernel is really executing SYSRET and
> we're on AMD, then we have the sysret_ss_attrs bug. If PVHVM has
> xen_pv_domain() returning true but also uses SYSRET for real, then
> this looks wrong.
HVM guests execute SYSRET and they will continue having
X86_BUG_SYSRET_SS_ATTRS flag on. PV guests OTOH don't do SYSRET, the
hypervisor does (which is why if this issue is to be fixed it would have
to be done in the hypervisor).
-boris
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests
@ 2015-05-05 14:21 ` Boris Ostrovsky
0 siblings, 0 replies; 10+ messages in thread
From: Boris Ostrovsky @ 2015-05-05 14:21 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-kernel, linux, Ingo Molnar, David Vrabel, H. Peter Anvin,
xen-devel, Thomas Gleixner
On 05/05/2015 09:51 AM, Andy Lutomirski wrote:
> On Mon, May 4, 2015 at 8:02 AM, Boris Ostrovsky
> <boris.ostrovsky@oracle.com> wrote:
>> Commit 61f01dd941ba ("x86_64, asm: Work around AMD SYSRET SS descriptor
>> attribute issue") makes AMD processors set SS to __KERNEL_DS in
>> __switch_to() to deal with cases when SS is NULL.
>>
>> This breaks Xen PV guests who do not want to load SS with__KERNEL_DS.
>>
>> Since the problem that the commit is trying to address would have to be
>> fixed in the hypervisor (if it in fact exists under Xen) there is no
>> reason to set X86_BUG_SYSRET_SS_ATTRS flag for PV VPCUs here.
>>
>> This can be easily achieved by adding x86_hyper_xen_hvm.set_cpu_features
>> op which will clear this flag. (And since this structure is no longer
>> HVM-specific we should do some renaming).
> Looks good to me, but:
>
>> static void __init xen_hvm_guest_init(void)
>> {
>> + if (xen_pv_domain())
>> + return;
>> +
> How can a platform be "hvm" and "pv"? Is that the PVHVM thing?
No, this is meant for "true" PV guest not to go through HVM-specific
initialization.
We have to do it since now x86_hyper_xen_hvm (renamed to x86_hyper_xen)
will have init_platform() op and so init_hypervisor_platform() will call
it obviously without knowing the type of the guest.
>
>> +static void xen_set_cpu_features(struct cpuinfo_x86 *c)
>> +{
>> + if (xen_pv_domain())
>> + clear_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
>> +}
> I haven't followed all the twists and turns, but, if the guest
> platform is such that the guest kernel is really executing SYSRET and
> we're on AMD, then we have the sysret_ss_attrs bug. If PVHVM has
> xen_pv_domain() returning true but also uses SYSRET for real, then
> this looks wrong.
HVM guests execute SYSRET and they will continue having
X86_BUG_SYSRET_SS_ATTRS flag on. PV guests OTOH don't do SYSRET, the
hypervisor does (which is why if this issue is to be fixed it would have
to be done in the hypervisor).
-boris
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests
2015-05-04 15:02 [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests Boris Ostrovsky
2015-05-05 13:51 ` Andy Lutomirski
2015-05-05 13:51 ` Andy Lutomirski
@ 2015-05-05 17:25 ` David Vrabel
2015-05-05 17:31 ` Boris Ostrovsky
2015-05-05 17:31 ` Boris Ostrovsky
2015-05-05 17:25 ` David Vrabel
3 siblings, 2 replies; 10+ messages in thread
From: David Vrabel @ 2015-05-05 17:25 UTC (permalink / raw)
To: Boris Ostrovsky, konrad.wilk, hpa, mingo, tglx
Cc: linux-kernel, xen-devel, linux, luto
On 04/05/15 16:02, Boris Ostrovsky wrote:
>
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1760,6 +1760,9 @@ static struct notifier_block xen_hvm_cpu_notifier = {
>
> static void __init xen_hvm_guest_init(void)
> {
> + if (xen_pv_domain())
> + return;
> +
I take Andy's point that this looks a little odd, perhaps...
static void __init xen_platform_init(void)
{
if (!xen_pv_domain())
xen_hvm_guest_init();
}
Would be a useful follow up?
I'll apply as-is though
David
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests
2015-05-04 15:02 [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests Boris Ostrovsky
` (2 preceding siblings ...)
2015-05-05 17:25 ` David Vrabel
@ 2015-05-05 17:25 ` David Vrabel
3 siblings, 0 replies; 10+ messages in thread
From: David Vrabel @ 2015-05-05 17:25 UTC (permalink / raw)
To: Boris Ostrovsky, konrad.wilk, hpa, mingo, tglx
Cc: xen-devel, luto, linux-kernel, linux
On 04/05/15 16:02, Boris Ostrovsky wrote:
>
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1760,6 +1760,9 @@ static struct notifier_block xen_hvm_cpu_notifier = {
>
> static void __init xen_hvm_guest_init(void)
> {
> + if (xen_pv_domain())
> + return;
> +
I take Andy's point that this looks a little odd, perhaps...
static void __init xen_platform_init(void)
{
if (!xen_pv_domain())
xen_hvm_guest_init();
}
Would be a useful follow up?
I'll apply as-is though
David
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests
2015-05-05 17:25 ` David Vrabel
2015-05-05 17:31 ` Boris Ostrovsky
@ 2015-05-05 17:31 ` Boris Ostrovsky
1 sibling, 0 replies; 10+ messages in thread
From: Boris Ostrovsky @ 2015-05-05 17:31 UTC (permalink / raw)
To: David Vrabel, konrad.wilk, hpa, mingo, tglx
Cc: linux-kernel, xen-devel, linux, luto
On 05/05/2015 01:25 PM, David Vrabel wrote:
> On 04/05/15 16:02, Boris Ostrovsky wrote:
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -1760,6 +1760,9 @@ static struct notifier_block xen_hvm_cpu_notifier = {
>>
>> static void __init xen_hvm_guest_init(void)
>> {
>> + if (xen_pv_domain())
>> + return;
>> +
> I take Andy's point that this looks a little odd, perhaps...
>
> static void __init xen_platform_init(void)
> {
> if (!xen_pv_domain())
> xen_hvm_guest_init();
> }
>
> Would be a useful follow up?
>
> I'll apply as-is though
>
Yes, this would look better. I can respin this if you want to avoid the
extra patch.
-boris
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests
2015-05-05 17:25 ` David Vrabel
@ 2015-05-05 17:31 ` Boris Ostrovsky
2015-05-05 17:31 ` Boris Ostrovsky
1 sibling, 0 replies; 10+ messages in thread
From: Boris Ostrovsky @ 2015-05-05 17:31 UTC (permalink / raw)
To: David Vrabel, konrad.wilk, hpa, mingo, tglx
Cc: xen-devel, luto, linux-kernel, linux
On 05/05/2015 01:25 PM, David Vrabel wrote:
> On 04/05/15 16:02, Boris Ostrovsky wrote:
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -1760,6 +1760,9 @@ static struct notifier_block xen_hvm_cpu_notifier = {
>>
>> static void __init xen_hvm_guest_init(void)
>> {
>> + if (xen_pv_domain())
>> + return;
>> +
> I take Andy's point that this looks a little odd, perhaps...
>
> static void __init xen_platform_init(void)
> {
> if (!xen_pv_domain())
> xen_hvm_guest_init();
> }
>
> Would be a useful follow up?
>
> I'll apply as-is though
>
Yes, this would look better. I can respin this if you want to avoid the
extra patch.
-boris
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests
@ 2015-05-04 15:02 Boris Ostrovsky
0 siblings, 0 replies; 10+ messages in thread
From: Boris Ostrovsky @ 2015-05-04 15:02 UTC (permalink / raw)
To: konrad.wilk, david.vrabel, hpa, mingo, tglx
Cc: xen-devel, boris.ostrovsky, luto, linux-kernel, linux
Commit 61f01dd941ba ("x86_64, asm: Work around AMD SYSRET SS descriptor
attribute issue") makes AMD processors set SS to __KERNEL_DS in
__switch_to() to deal with cases when SS is NULL.
This breaks Xen PV guests who do not want to load SS with__KERNEL_DS.
Since the problem that the commit is trying to address would have to be
fixed in the hypervisor (if it in fact exists under Xen) there is no
reason to set X86_BUG_SYSRET_SS_ATTRS flag for PV VPCUs here.
This can be easily achieved by adding x86_hyper_xen_hvm.set_cpu_features
op which will clear this flag. (And since this structure is no longer
HVM-specific we should do some renaming).
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
---
v2:
* Adjusted ifdefs to account for !CONFIG_PVHVM case
* Renamed xen_guest_init() back to xen_hvm_guest_init()
arch/x86/include/asm/hypervisor.h | 2 +-
arch/x86/kernel/cpu/hypervisor.c | 4 ++--
arch/x86/xen/enlighten.c | 28 +++++++++++++++++++---------
3 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/arch/x86/include/asm/hypervisor.h b/arch/x86/include/asm/hypervisor.h
index e42f758..055ea99 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -50,7 +50,7 @@ extern const struct hypervisor_x86 *x86_hyper;
/* Recognized hypervisors */
extern const struct hypervisor_x86 x86_hyper_vmware;
extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
-extern const struct hypervisor_x86 x86_hyper_xen_hvm;
+extern const struct hypervisor_x86 x86_hyper_xen;
extern const struct hypervisor_x86 x86_hyper_kvm;
extern void init_hypervisor(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index 36ce402..d820d8e 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -27,8 +27,8 @@
static const __initconst struct hypervisor_x86 * const hypervisors[] =
{
-#ifdef CONFIG_XEN_PVHVM
- &x86_hyper_xen_hvm,
+#ifdef CONFIG_XEN
+ &x86_hyper_xen,
#endif
&x86_hyper_vmware,
&x86_hyper_ms_hyperv,
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 94578ef..ac3427a 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1760,6 +1760,9 @@ static struct notifier_block xen_hvm_cpu_notifier = {
static void __init xen_hvm_guest_init(void)
{
+ if (xen_pv_domain())
+ return;
+
init_hvm_pv_info();
xen_hvm_init_shared_info();
@@ -1775,6 +1778,7 @@ static void __init xen_hvm_guest_init(void)
xen_hvm_init_time_ops();
xen_hvm_init_mmu_ops();
}
+#endif
static bool xen_nopv = false;
static __init int xen_parse_nopv(char *arg)
@@ -1784,14 +1788,11 @@ static __init int xen_parse_nopv(char *arg)
}
early_param("xen_nopv", xen_parse_nopv);
-static uint32_t __init xen_hvm_platform(void)
+static uint32_t __init xen_platform(void)
{
if (xen_nopv)
return 0;
- if (xen_pv_domain())
- return 0;
-
return xen_cpuid_base();
}
@@ -1809,11 +1810,20 @@ bool xen_hvm_need_lapic(void)
}
EXPORT_SYMBOL_GPL(xen_hvm_need_lapic);
-const struct hypervisor_x86 x86_hyper_xen_hvm __refconst = {
- .name = "Xen HVM",
- .detect = xen_hvm_platform,
+static void xen_set_cpu_features(struct cpuinfo_x86 *c)
+{
+ if (xen_pv_domain())
+ clear_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
+}
+
+const struct hypervisor_x86 x86_hyper_xen = {
+ .name = "Xen",
+ .detect = xen_platform,
+#ifdef CONFIG_XEN_PVHVM
.init_platform = xen_hvm_guest_init,
+#endif
.x2apic_available = xen_x2apic_para_available,
+ .set_cpu_features = xen_set_cpu_features,
};
-EXPORT_SYMBOL(x86_hyper_xen_hvm);
-#endif
+EXPORT_SYMBOL(x86_hyper_xen);
+
--
1.9.3
^ permalink raw reply related [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-05-05 17:33 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-04 15:02 [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests Boris Ostrovsky
2015-05-05 13:51 ` Andy Lutomirski
2015-05-05 13:51 ` Andy Lutomirski
2015-05-05 14:21 ` Boris Ostrovsky
2015-05-05 14:21 ` Boris Ostrovsky
2015-05-05 17:25 ` David Vrabel
2015-05-05 17:31 ` Boris Ostrovsky
2015-05-05 17:31 ` Boris Ostrovsky
2015-05-05 17:25 ` David Vrabel
2015-05-04 15:02 Boris Ostrovsky
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.