All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] x86-64: don't allow wrmsr to MSR_FAM10H_MMIO_CONF_BASE when Xen itself is using it
@ 2011-01-07  8:10 Jan Beulich
  2011-01-10  8:54 ` Keir Fraser
  0 siblings, 1 reply; 3+ messages in thread
From: Jan Beulich @ 2011-01-07  8:10 UTC (permalink / raw)
  To: xen-devel@lists.xensource.com

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

Signed-off-by: Jan Beulich <jbeulich@novell.com>

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1695,6 +1695,10 @@ static int is_cpufreq_controller(struct 
             (d->domain_id == 0));
 }
 
+#ifdef CONFIG_X86_64
+#include "x86_64/mmconfig.h"
+#endif
+
 static int emulate_privileged_op(struct cpu_user_regs *regs)
 {
     struct vcpu *v = current;
@@ -2289,7 +2293,14 @@ static int emulate_privileged_op(struct 
                 goto fail;
             if ( !IS_PRIV(v->domain) )
                 break;
-            if ( (rdmsr_safe(MSR_FAM10H_MMIO_CONF_BASE, val) != 0) ||
+            if ( (rdmsr_safe(MSR_FAM10H_MMIO_CONF_BASE, val) != 0) )
+                goto fail;
+            if (
+#ifdef CONFIG_X86_64
+                 (pci_probe & PCI_PROBE_MMCONF) &&
+                 (pci_probe & PCI_CHECK_ENABLE_AMD_MMCONF) ?
+                 val != msr_content :
+#endif
                  ((val ^ msr_content) &
                   ~( FAM10H_MMIO_CONF_ENABLE |
                     (FAM10H_MMIO_CONF_BUSRANGE_MASK <<




[-- Attachment #2: x86_64-fam10-mmconf-wrmsr.patch --]
[-- Type: text/plain, Size: 1068 bytes --]

Signed-off-by: Jan Beulich <jbeulich@novell.com>

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1695,6 +1695,10 @@ static int is_cpufreq_controller(struct 
             (d->domain_id == 0));
 }
 
+#ifdef CONFIG_X86_64
+#include "x86_64/mmconfig.h"
+#endif
+
 static int emulate_privileged_op(struct cpu_user_regs *regs)
 {
     struct vcpu *v = current;
@@ -2289,7 +2293,14 @@ static int emulate_privileged_op(struct 
                 goto fail;
             if ( !IS_PRIV(v->domain) )
                 break;
-            if ( (rdmsr_safe(MSR_FAM10H_MMIO_CONF_BASE, val) != 0) ||
+            if ( (rdmsr_safe(MSR_FAM10H_MMIO_CONF_BASE, val) != 0) )
+                goto fail;
+            if (
+#ifdef CONFIG_X86_64
+                 (pci_probe & PCI_PROBE_MMCONF) &&
+                 (pci_probe & PCI_CHECK_ENABLE_AMD_MMCONF) ?
+                 val != msr_content :
+#endif
                  ((val ^ msr_content) &
                   ~( FAM10H_MMIO_CONF_ENABLE |
                     (FAM10H_MMIO_CONF_BUSRANGE_MASK <<

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] x86-64: don't allow wrmsr to MSR_FAM10H_MMIO_CONF_BASE when Xen itself is using it
  2011-01-07  8:10 [PATCH] x86-64: don't allow wrmsr to MSR_FAM10H_MMIO_CONF_BASE when Xen itself is using it Jan Beulich
@ 2011-01-10  8:54 ` Keir Fraser
  2011-01-10  9:07   ` Jan Beulich
  0 siblings, 1 reply; 3+ messages in thread
From: Keir Fraser @ 2011-01-10  8:54 UTC (permalink / raw)
  To: Jan Beulich, xen-devel@lists.xensource.com

Applied, thanks. Is similar needed in 4.0-testing? It doesn't trivially
backport since 4.0-testing does not have other of your patches which also
serves to make variable pci_probe non-static.

 -- Keir

On 07/01/2011 08:10, "Jan Beulich" <JBeulich@novell.com> wrote:

> Signed-off-by: Jan Beulich <jbeulich@novell.com>
> 
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1695,6 +1695,10 @@ static int is_cpufreq_controller(struct
>              (d->domain_id == 0));
>  }
>  
> +#ifdef CONFIG_X86_64
> +#include "x86_64/mmconfig.h"
> +#endif
> +
>  static int emulate_privileged_op(struct cpu_user_regs *regs)
>  {
>      struct vcpu *v = current;
> @@ -2289,7 +2293,14 @@ static int emulate_privileged_op(struct
>                  goto fail;
>              if ( !IS_PRIV(v->domain) )
>                  break;
> -            if ( (rdmsr_safe(MSR_FAM10H_MMIO_CONF_BASE, val) != 0) ||
> +            if ( (rdmsr_safe(MSR_FAM10H_MMIO_CONF_BASE, val) != 0) )
> +                goto fail;
> +            if (
> +#ifdef CONFIG_X86_64
> +                 (pci_probe & PCI_PROBE_MMCONF) &&
> +                 (pci_probe & PCI_CHECK_ENABLE_AMD_MMCONF) ?
> +                 val != msr_content :
> +#endif
>                   ((val ^ msr_content) &
>                    ~( FAM10H_MMIO_CONF_ENABLE |
>                      (FAM10H_MMIO_CONF_BUSRANGE_MASK <<
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] x86-64: don't allow wrmsr to MSR_FAM10H_MMIO_CONF_BASE when Xen itself is using it
  2011-01-10  8:54 ` Keir Fraser
@ 2011-01-10  9:07   ` Jan Beulich
  0 siblings, 0 replies; 3+ messages in thread
From: Jan Beulich @ 2011-01-10  9:07 UTC (permalink / raw)
  To: Keir Fraser; +Cc: xen-devel@lists.xensource.com

>>> On 10.01.11 at 09:54, Keir Fraser <keir@xen.org> wrote:
> Applied, thanks. Is similar needed in 4.0-testing? It doesn't trivially
> backport since 4.0-testing does not have other of your patches which also
> serves to make variable pci_probe non-static.

We don't have full support for PCI_CHECK_ENABLE_AMD_MMCONF
in 4.0 anyway, so this not clear whether there would be much benefit
from the change here.

However, as you mention it and I now think about it from a slightly
different perspective - perhaps having the (pci_probe &
PCI_CHECK_ENABLE_AMD_MMCONF) check in here isn't correct at
all - we really only should check whether we're using mmconf. From
that angle, having this in 4.0 would certainly be desirable, as
otherwise the mmconf window could move under our feet.

Yet again when mmconf is enabled (FAM10H_MMIO_CONF_ENABL set)
no version of Linux wouldn't move the window either, so the change
would only be a theoretical safe guard.

Hence altogether probably not worth the effort for 4.0, the more
that the whole thing still isn't complete, as the E820 interaction
hasn't seen a decision so far (neither on the Linux side).

Jan

> On 07/01/2011 08:10, "Jan Beulich" <JBeulich@novell.com> wrote:
> 
>> Signed-off-by: Jan Beulich <jbeulich@novell.com>
>> 
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -1695,6 +1695,10 @@ static int is_cpufreq_controller(struct
>>              (d->domain_id == 0));
>>  }
>>  
>> +#ifdef CONFIG_X86_64
>> +#include "x86_64/mmconfig.h"
>> +#endif
>> +
>>  static int emulate_privileged_op(struct cpu_user_regs *regs)
>>  {
>>      struct vcpu *v = current;
>> @@ -2289,7 +2293,14 @@ static int emulate_privileged_op(struct
>>                  goto fail;
>>              if ( !IS_PRIV(v->domain) )
>>                  break;
>> -            if ( (rdmsr_safe(MSR_FAM10H_MMIO_CONF_BASE, val) != 0) ||
>> +            if ( (rdmsr_safe(MSR_FAM10H_MMIO_CONF_BASE, val) != 0) )
>> +                goto fail;
>> +            if (
>> +#ifdef CONFIG_X86_64
>> +                 (pci_probe & PCI_PROBE_MMCONF) &&
>> +                 (pci_probe & PCI_CHECK_ENABLE_AMD_MMCONF) ?
>> +                 val != msr_content :
>> +#endif
>>                   ((val ^ msr_content) &
>>                    ~( FAM10H_MMIO_CONF_ENABLE |
>>                      (FAM10H_MMIO_CONF_BUSRANGE_MASK <<
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com 
>> http://lists.xensource.com/xen-devel 

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-01-10  9:07 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-07  8:10 [PATCH] x86-64: don't allow wrmsr to MSR_FAM10H_MMIO_CONF_BASE when Xen itself is using it Jan Beulich
2011-01-10  8:54 ` Keir Fraser
2011-01-10  9:07   ` Jan Beulich

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.