On 04/09/2019 10:26, Jan Beulich wrote:
> On 03.09.2019 14:34, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -545,6 +545,11 @@ void recalculate_cpuid_policy(struct dom
>>>
>>> p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
>>>
>>> +if ( p->extd.r
On 03.09.2019 14:34, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -545,6 +545,11 @@ void recalculate_cpuid_policy(struct dom
>>
>> p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
>>
>> +if ( p->extd.rdpru )
>> +p->extd.rdpru_max = min(p->ext
On 03.09.2019 14:34, Andrew Cooper wrote:
> On 03/09/2019 10:41, Jan Beulich wrote:
>> While the PM doesn't say so, this assumes that the MPERF value read this
>> way gets scaled similarly to its reading through RDMSR.
>>
>> Signed-off-by: Jan Beulich
>
> This wants the following hunks merged, to
On 03/09/2019 10:41, Jan Beulich wrote:
> While the PM doesn't say so, this assumes that the MPERF value read this
> way gets scaled similarly to its reading through RDMSR.
>
> Signed-off-by: Jan Beulich
This wants the following hunks merged, to at least keep the
intercept/exit codes up to date.
While the PM doesn't say so, this assumes that the MPERF value read this
way gets scaled similarly to its reading through RDMSR.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -257,6 +257,7 @@ int libxl_cpuid_parse_config(libxl_cpuid