[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC for-4.15] x86/msr: introduce an option for legacy MSR behavior selection
- To: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Thu, 4 Mar 2021 14:02:46 +0000
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9kY1RiySxJVmmLrMh4G/PkrsIu4+mS6ldgF6SoRjiL0=; b=dTxJJ5ft/SctA2hprj257n2zafSCyGtcjWWz3qHiyXqFp9Wb4fWCTqM6kJtfRa9pGh+JC0c/E6nsn3GJOOoSyCZ5PIfYRfmpzKqcQZ2ZBrTNaTMh5zAMRwitoTaJjLEyVxrK8tnSNvnj1irWkm9h/jeWvtWfIufOd4AcEalSIhvlpy0oUqAN4dYBPvHbcMrtFwih7cUA4PBy8C1nb4je5lDT6fyjZY4VHIUyOVvfSd6g3LeU8GlwQpodjPVYwXKARcHAxUWmBr12vradfu706hIw6mYrQ8w/n0V2J7nZRBGKAkDLh3UYk2itqpmfS5Oowwunf9GZcbnsMc2Z7l5dPA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VvFj4TWZevPa1/zBdke4C4RditX4s3wjEGkfw5r5BezKe0bvMrtkxSjUboQAmZv1VOR6ihyu7aNNb68YuqtkQlgHni1aXnfdWjJ8hf0m/9QnzDHKJ2CPfZMZrr30iTaPNIbbrvgG2FPJsdFuJ2yXgJNl2hNsWkh+8lBpYbkDNC9auO0cvwbkUN8ClG37v5o5rmWLNyQsh5nek9KfcXhj03XdmF21JGIukHU38DfyaAxb823/SH0GaKisI9QOfjAWXsK1PatCITC80SlRbH3TJXY/oLw5vM2Yg+AHw1JREHyhFtC+ti4yR1whC4Z738oodJBT278yFrs1xEAMb/W20w==
- Authentication-results: esa5.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
- Cc: Ian Jackson <iwj@xxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>
- Delivery-date: Thu, 04 Mar 2021 14:08:36 +0000
- Ironport-sdr: jKOASyZRbuJvcKIjLWOyyETmKBNpP2RoSclQvuIhQ66R7/Y7gxJVULjJrwismzVLGcS5mis7yE 4Be44oh5pOEtzkg1y0/rrqe0dQ2+Whav0YVG1M7eOdl3284bm49G4VnphbOepwRtidkws5zBdK jaFnxLcJhMc1v68asveIEqcfknD3NoavS3qOHlWAIqocu+JJujudV2EaFPa1fpGQO6EzbXF1kn xM/T6+AHbxCwDpdHQ6cbNwpy99fgFVcvzJFX7ZWJltQ9mNnunv5qYq67L7plZQEa51HBT1YoHv fkw=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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.pau@xxxxxxxxxx>
>> ---
>> Cc: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
>> ---
>> 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
|
