From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH] Allow dom0 to write MSR IA32_ENERGY_PERF_BIAS Date: Wed, 05 Jan 2011 08:31:22 +0000 Message-ID: <4D243A6A020000780002A658@vpn.id2.novell.com> References: <4D24371B020000780002A62B@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Gang Wei , Keir Fraser Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org >>> On 05.01.11 at 09:22, Keir Fraser wrote: > On 05/01/2011 08:17, "Jan Beulich" wrote: >=20 >>>>> On 05.01.11 at 09:13, Keir Fraser wrote: >>> On 05/01/2011 07:59, "Jan Beulich" wrote: >>>=20 >>>>>> Why would you allow this only if Dom0 has its vcpus pinned? >>>>>=20 >>>>> It is meaningless if dom0 can't control all pcpus exactly. Only in = case of >>>>> dom0 vcpus pinned, it makes sense. >>>>=20 >>>> 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). >>>=20 >>> If so, it deserves a separate patch to strip out *all* the is_pinned = checks >>> at the same time. >>=20 >> You certainly don't mean *all*, but yes, I'm intending to submit such >> a patch. >=20 > 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. Jan