WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] x86-64: don't allow wrmsr to MSR_FAM10H_MMIO_CON

To: "Keir Fraser" <keir@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH] x86-64: don't allow wrmsr to MSR_FAM10H_MMIO_CONF_BASE when Xen itself is using it
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Mon, 10 Jan 2011 09:07:13 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 10 Jan 2011 01:08:07 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C95079AA.29F59%keir@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D26D88F020000780002AEEA@xxxxxxxxxxxxxxxxxx> <C95079AA.29F59%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 10.01.11 at 09:54, Keir Fraser <keir@xxxxxxx> 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@xxxxxxxxxx> wrote:
> 
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>> 
>> --- 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@xxxxxxxxxxxxxxxxxxx 
>> http://lists.xensource.com/xen-devel 




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

<Prev in Thread] Current Thread [Next in Thread>