On 04/03/2021 14:02, Andrew Cooper wrote: > 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?
Actually never mind. I've figured out why. I have another bugfix to submit. ~Andrew
