Re: [Xen-devel] [PATCH] RFC: Linux: disable APERF/MPERF feature in PV kernels

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 23/05/12 13:18, Jan Beulich wrote:
>>>> On 23.05.12 at 13:11, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel