On 22/05/12 17:52, Jeremy Fitzhardinge wrote:
> On 05/22/2012 09:07 AM, Andre Przywara wrote:
>> Hi,
>>
>> while testing some APERF/MPERF semantics I discovered that this
>> feature is enabled in Xen Dom0, but is not reliable.
>> The Linux kernel's scheduler uses this feature if it sees the CPUID
>> bit, leading to costly RDMSR traps (a few 100,000s during a kernel
>> compile) and bogus values due to VCPU migration during the measurement.
>> The attached patch explicitly disables this CPU capability inside the
>> Linux kernel, I couldn't measure any APERF/MPERF reads anymore with
>> the patch applied.
>> I am not sure if the PVOPS code is the right place to fix this, we
>> could as well do it in the HV's xen/arch/x86/traps.c:pv_cpuid().
>> Also when the Dom0 VCPUs are pinned, we could allow this, but I am not
>> sure if it's worth to do so.
> Seems reasonable to me.  Do all those RDMSR traps have a measurable
> performance effect?
>
> Also, is there a symbolic constant for that bit?
>
>      J
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
Hi,

I've attached a patch which masks the matching CPUID leaves in the Xen pv_cpuid function.
Should the logic in pv_cpuid be changed to only pass through explictly allowed CPUID leaves rather than masking
them using case statements?

Malcolm