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] Allow dom0 to write MSR IA32_ENERGY_PERF_BIAS

To: Jan Beulich <JBeulich@xxxxxxxxxx>, Keir Fraser <keir@xxxxxxx>
Subject: RE: [Xen-devel] [PATCH] Allow dom0 to write MSR IA32_ENERGY_PERF_BIAS
From: "Wei, Gang" <gang.wei@xxxxxxxxx>
Date: Wed, 5 Jan 2011 16:55:23 +0800
Accept-language: zh-CN, en-US
Acceptlanguage: zh-CN, en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>
Delivery-date: Wed, 05 Jan 2011 00:57:03 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D243A6A020000780002A658@xxxxxxxxxxxxxxxxxx>
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: <4D24371B020000780002A62B@xxxxxxxxxxxxxxxxxx> <C949DAD6.1102B%keir@xxxxxxx> <4D243A6A020000780002A658@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcussycaAndS/ZrsRLS69jioMPx+fAAAnuSQ
Thread-topic: [Xen-devel] [PATCH] Allow dom0 to write MSR IA32_ENERGY_PERF_BIAS
Jan Beulich wrote on 2011-01-05:
>>>> On 05.01.11 at 09:22, Keir Fraser <keir@xxxxxxx> wrote:
>> On 05/01/2011 08:17, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>> 
>>>>>> On 05.01.11 at 09:13, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:
>>>> On 05/01/2011 07:59, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>>>> 
>>>>>>> Why would you allow this only if Dom0 has its vcpus pinned?
>>>>>> 
>>>>>> It is meaningless if dom0 can't control all pcpus exactly. Only
>>>>>> in case of dom0 vcpus pinned, it makes sense.
>>>>> 
>>>>> Disagree. The user mode tool could set its own affinity (virtual
>>>>> and
>>>>> physical) and then issue the MSR write. Please don't enforce
>>>>> restrictions where not really needed (I actually suppose that the
>>>>> restriction should be removed for MSR_IA32_THERM_CONTROL too).

Ok, I accept such kind of usages. So how about simply check in my patch and do 
remove these restrictions in your following patches?

>>>> 
>>>> If so, it deserves a separate patch to strip out *all* the
>>>> is_pinned checks at the same time.
>>> 
>>> You certainly don't mean *all*, but yes, I'm intending to submit
>>> such a patch.
>> 
>> The ones in x86/traps.c (WRMSR emulation) and x86/domain.c
>> (VCPUOP_get_physid) are both unnecessary, at least.
> 
> They aren't outright unnecessary I'd say, they just need some relaxing
> (as the code makes sense also when the vCPU is constrained to a single
> pCPU). That's the change I'm going to send shortly.


Jimmy



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