[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:17:59 +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=+n979Kpzz3wOb0UKzWhsUCl9o6Pi8vFOEIIokHfCfXo=; b=A15GCECx6rVJDPINYoFGVwG28RlwoUTib+J7uEOWVzSKMXE3iJ05mdY+9a9HhOIQ/7uT4QzqRNvwfWySozyISk95dwLVqNsHEkpbx6luSFG/VtK9tELEnkKxqsg6hJj+2dgiAKgO/uZNmYAsP2G6jF0eYyOaCOu04iTgOsr/nV2N5e6Jzn2a0s55LwB8aLlFhqnKhAqUoCYiaLs3Py4/qA6Lr8SnaTiqFv/rgDnaKfXuDP1JrxN9bKPXRnmU4pfwldP1nIvgxflhZUPsX5sqiXwQwSVnxPCWyFddwyOEPZnsfoPjFYAkkTt+KB8mROZIYYJHoo0QXneFJ/ATUXJwMw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RBC7jsPxlYoQs9kFAp216EJTHU/6ybnGkmswRQBoV30m0stC/O5M13y2F4zBuUTZdnwU0APo6ev439r3Kfeq7iVT3W08oJYPBWM+B/fSjvjoeXqhh4zW2RAbsZEpF4j7F8b+A7YjEZcUjSPYKuP+mTTf7SDw43xst4tZ2kUawm0IBgfWtxOLEHxXtCY3Sbp8zPAX0+F18V/ABtca3DhYwO+CSQOapyEO4pAxdRua+OZJhsHl0VEaj8vn3sW94+4u0YKh3ZbydanOxsPl1w8HTzbKsmFiyf9eeufP21YltHAYCWngdU8BJbhJLMSRfrOZ9dYziC3WZJ4pzi8xBZio7g==
- Authentication-results: esa2.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:18:30 +0000
- Ironport-sdr: aYXISfdobRBRLsnE99fSDYABW+YJxhXhnATtlMnDKrwA10lJPuHbOUPV4BblQIHogQttc0RT76 lCZDlfgVwabsGAOsgtN1P0sPFpwSDLPWcEfW15GgKRwYsjWlicf+V9a5xJt/qzxGkElHjApHmQ U19l7oZjGvDIfT16DQcLM6PumD0aRnxAeAMARRjgScVe5iHKtDpQnWv2+knNpjsBGAWGOwe7Hr IKfo5VOTnBk+naNuhgpDDqTNHs9uK/KG+yWoY3SIqEZMj3XH29wfwxYmZaRU1a5jyGfKKSh0J9 eBI=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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.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?
Actually never mind. I've figured out why. I have another bugfix to
submit.
~Andrew
|
