On 23/06/15 16:09, Konrad Rzeszutek Wilk wrote:
* Leaf 0x0007[ECX=0].EAX
* `mask_l7s0_ebx`
>>> Those 'l' look like '1' in the PDF.
>>>
>>> Can it be called something else?
>> If you can suggest a better name, yes. As for now, these are the
>> variable names used in-tree (top of x
> >> * Leaf 0x0007[ECX=0].EAX
> >> * `mask_l7s0_ebx`
> > Those 'l' look like '1' in the PDF.
> >
> > Can it be called something else?
>
> If you can suggest a better name, yes. As for now, these are the
> variable names used in-tree (top of xen/arch/x86/cpu/amd.c)
low?
>
> >
> >> *
On 22/06/15 20:18, Konrad Rzeszutek Wilk wrote:
> Thank you for posting this!
>
> Some comments below.
>
>> Design
>> ==
>>
>> `struct sysctl_physinfo.levelling_caps`
>> ---
>>
>> Xen shall gain a new physinfo field which reports the degree to which it can
>>
Thank you for posting this!
Some comments below.
> Design
> ==
>
> `struct sysctl_physinfo.levelling_caps`
> ---
>
> Xen shall gain a new physinfo field which reports the degree to which it can
> influence `CPUID` executed by a PV guest. This is a bitmap
On 16/06/15 16:33, Jan Beulich wrote:
On 16.06.15 at 12:50, wrote:
>> How XenServer currently does levelling
>> ==
>>
>> The _Heterogeneous Pool Levelling_ support in XenServer appears to
>> predate the
>> libxc CPUID policy API, so does not currently use i
>>> On 16.06.15 at 12:50, wrote:
> How XenServer currently does levelling
> ==
>
> The _Heterogeneous Pool Levelling_ support in XenServer appears to
> predate the
> libxc CPUID policy API, so does not currently use it. The toolstack has a
> table of CPU model
