>>> 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,
>>> uint64_t *val)
>>> _MSR_MISC_FEAT
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 functionally
>> depends on RD
>>> 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 sure this isn't a documentat
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.
>
> For
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.
>
> For
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
writes
