On 01/03/2021 19:33, Boris Ostrovsky wrote:
> On 3/1/21 11:23 AM, Roger Pau Monne wrote:
>> Introduce an option to allow selecting the legacy behavior for
>> accesses to MSRs not explicitly handled. Since commit
>> 84e848fd7a162f669 and 322ec7c89f6640e accesses to MSRs not explicitly
>> handled by Xen result in the injection of a #GP to the guest. This is
>> a behavior change since previously a #GP was only injected if
>> accessing the MSR on the real hardware will also trigger a #GP.
>>
>> This seems to be problematic for some guests, so introduce an option
>> to fallback to this legacy behavior. The main difference between what
>> was previously done is that the hardware MSR value is not leaked to
>> the guests on reads.
>>
>> Signed-off-by: Roger Pau Monné <roger....@citrix.com>
>> ---
>> Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
>> ---
>> Note that this option is not made available to dom0. I'm not sure
>> whether it makes sense to do so, since anyone updating Xen to such
>> newer version will also likely pair it with a newish kernel that
>> doesn't require such workarounds.
>>
>> RFC because there's still some debate as to how we should solve the
>> MSR issue, this is one possible way, but IMO we need to make a
>> decision soon-ish because of the release timeline.
>>
>> Boris, could you please test with Solaris to see if this fixes the
>> issue?
>
> Yes, it does. Thanks.

Really?  This doesn't stop #GP being raised for RAPL_POWER_LIMIT
AFAICT.  Or am I mistaken about how the bug manifested?

~Andrew

Reply via email to