From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] RFC: Linux: disable APERF/MPERF feature in PV kernels Date: Wed, 23 May 2012 14:21:23 +0100 Message-ID: <4FBCE453.5080206@citrix.com> References: <4FBBB9AF.6020704@amd.com> <4FBCAF1902000078000855C5@nat28.tlf.novell.com> <4FBCC5F3.1080804@citrix.com> <4FBCF1B902000078000857D7@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4FBCF1B902000078000857D7@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Andre Przywara , Jeremy Fitzhardinge , xen-devel , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On 23/05/12 13:18, Jan Beulich wrote: >>>> On 23.05.12 at 13:11, Andrew Cooper wrote: >> On 23/05/12 08:34, Jan Beulich wrote: >>> First of all I'm of the opinion that this indeed should not be >>> masked in the hypervisor - there's no reason to disallow the >>> guest to read these registers (but we should of course deny >>> writes as long as Xen is controlling P-states, which we do). >> I am sorry but I am going to have to disagree with you on this point. >> >> We should not be advertising this feature to any guest at all if we >> can't provide an implementation which works as native expects. Else we >> are failing in our job of virtualisation. > That's perhaps a matter of the position you take - for HVM, I > would agree with yours, but there's many more aspects (not > the least related to accessing other MSRs) that we fail to > "properly" virtualize for PV guests - my position is that it is the > nature of PV that guest kernels have to be aware of being > virtualized (and hence stay away from doing certain things > unless [they think] they know what they're doing). > >> There is 'dom0_vcpus_pin'[1] which identity pins dom0 vcpus, and >> prevents update of the affinity masks, and appears to conditionally >> allow access to certain MSRs. I think it would be fine to expose this >> feature iff dom0s vcpus are pinned in this fashion. That way, the >> measurement should succeed, even if dom0 only has read access to the MSRs. > Restricting it to this case would be too restrictive - it really > makes sense at any time where the vCPU's affinity has exactly > one bit set (or to be precise, the intersection of it and the set > of online pCPU-s). > > Jan > That is unfortunately too lax. You also need to be able to guarantee that the affinity mask is not updated (and vcpu rescheduled) while in the middle of a measurement. Xen cant sensibly work out if or when a guest is taking a measurement, nor can dom0. So the only safe solution I can see is for Xen to prevent the affinity masks from ever being updated. With more thought, this would also preclude migration of a guest to another host. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com