On 19.07.2023 03:17, Marek Marczykowski-Górecki wrote:
> On Wed, Jul 19, 2023 at 12:38:39AM +0200, Simon Gaiser wrote:
>> Jan Beulich:
>>> On 18.07.2023 15:17, Simon Gaiser wrote:
>>>> --- a/xen/arch/x86/pv/emul-priv-op.c
>>>> +++ b/xen/arch/x86/pv/emul-priv-op.c
>>>> @@ -965,6 +965,20 @@ static int cf_check read_msr(
>>>>          *val = 0;
>>>>          return X86EMUL_OKAY;
>>>>  
>>>> +    case MSR_PKG_C2_RESIDENCY:
>>>> +    case MSR_PKG_C3_RESIDENCY:
>>>> +    case MSR_PKG_C6_RESIDENCY:
>>>> +    case MSR_PKG_C7_RESIDENCY:
>>>> +    case MSR_PKG_C8_RESIDENCY:
>>>> +    case MSR_PKG_C9_RESIDENCY:
>>>> +    case MSR_PKG_C10_RESIDENCY:
>>>> +        if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>>>> +            break;
>>>> +        if ( is_hardware_domain(currd) )
>>>> +            goto normal;
>>>> +        *val = 0;
>>>> +        return X86EMUL_OKAY;
>>>
>>> In addition to what Andrew said: Why would we suddenly allow these
>>> reads to succeed for DomU-s?
>>
>> That patch wouldn't actually allow those reads, but fake a 0 response,
>> or do I miss something. If you mean that behavior: I just mirrored what
>> is done there in some of the other cases. If you prefer something else,
>> for example treating it as unimplemented, I can change that.
> 
> I think Jan meant exactly this difference - faking 0, instead of
> failing the read.

Indeed.

Jan


Reply via email to