>>> On 23.02.18 at 16:51, wrote:
> On 23/02/18 15:05, Jan Beulich wrote:
> On 21.02.18 at 12:36, wrote:
>>> --- a/xen/arch/x86/msr.c
>>> +++ b/xen/arch/x86/msr.c
>>> @@ -175,6 +175,13 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr,
On 23/02/18 15:05, Jan Beulich wrote:
On 21.02.18 at 12:36, wrote:
>> There are many problems with MSR_TSC_AUX handling.
>>
>> To begin with, the RDPID instruction reads MSR_TSC_AUX, but it is only the
>> RDTSCP feature which enumerates the MSR. Therefore, RDPID
>>> On 21.02.18 at 12:36, wrote:
> There are many problems with MSR_TSC_AUX handling.
>
> To begin with, the RDPID instruction reads MSR_TSC_AUX, but it is only the
> RDTSCP feature which enumerates the MSR. Therefore, RDPID functionally
> depends on RDTSCP.
Are you
On Wed, Feb 21, 2018 at 11:36:15AM +, Andrew Cooper wrote:
> There are many problems with MSR_TSC_AUX handling.
>
> To begin with, the RDPID instruction reads MSR_TSC_AUX, but it is only the
> RDTSCP feature which enumerates the MSR. Therefore, RDPID functionally
> depends on RDTSCP.
>
>
There are many problems with MSR_TSC_AUX handling.
To begin with, the RDPID instruction reads MSR_TSC_AUX, but it is only the
RDTSCP feature which enumerates the MSR. Therefore, RDPID functionally
depends on RDTSCP.
For PV guests, we hide RDTSCP but advertise RDPID. We also silently drop