[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH v3] x86/amd: do not expose HWCR.TscFreqSel to guests
- To: xen-devel@xxxxxxxxxxxxxxxxxxxx
- From: Roger Pau Monne <roger.pau@xxxxxxxxxx>
- Date: Thu, 14 Sep 2023 16:54:36 +0200
- 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=knDgYklc6VT0ex6NEBjcbufcJ5EGGOD3BbMq/Zww6nw=; b=Ip8+f/rvyJdf7LPm33hIW4CVMoT2t2tmzojNFDQ/jesQzs9yYTbYZWCr7RU6WaNgb1EeeH6hGH49kkkybmqtWcXbyrlQLrtFPc+DWILvI+U5bvymMC3lPc6RwwyH1HskJKaZ+ajdlpvsV89arJVwBfbMLw1TcA+QBck46dnJfbAaN2eZdirvFLobT17wU3wiTIdZeLRCy86TtbycxEUHZxAKV8f4X5DXgjBQ+MI6EqGnDTJ6Gf/sfO6up92EHVapNh/kouQG7jHeoEcdpwe7XU6IwewRTorRlV5+41T3qz2uy5g6AH35WszFkTMM1Gx+lI7thNgBJCNF2uYonl4LeA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n4eDCsVwIREddypJRWeR8HO+qk9A3sh5bDmpGS/m9UPh0gDNrvUrNI1W3jNTgFA3ZIWPcSdKGaWvc+i9kZk51yIAPYu1qgTYiHYmKqdrUI2TQXPbb+x1nBaA9HjIixO3CE5j/a0US8hoim+GWlAVbCA2Nea6RGwSpcOBIHo02/8U1RuTxSuNHZYPXTiQknlayu7SA5O7AqFYDQoJYtuP1f0dBfsYo4nEf8S76REn+8TYGi/Shfdb7USHpH+2KEUjRCPbqVOTcmFOy1GhRTsMftlEgtkLXReaakD2hw7nzClzCzZL2U2Nxmwv+TT7ItPNHXh0dWeeyorp09LiiPvw8Q==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Solène Rapenne <solene@xxxxxxxxxxx>
- Delivery-date: Thu, 14 Sep 2023 14:55:27 +0000
- Ironport-data: A9a23:jOyt/qo9g8lmzFFv6S96dnR6XNteBmIrZBIvgKrLsJaIsI4StFCzt garIBmEaayMZmHzctgjbti//BgP7MCDnIcyTwc6+y1mRX8WpZuZCYyVIHmrMnLJJKUvbq7FA +Y2MYCccZ9uHhcwgj/3b9ANeFEljfngqoLUUbOCYmYpA1Y8FE/NsDo788YhmIlknNOlNA2Ev NL2sqX3NUSsnjV5KQr40YrawP9UlKq04GlwUmAWP6gR5wePziVNV/rzGInqR5fGatgMdgKFb 76rIIGRpgvx4xorA9W5pbf3GmVirmn6ZFXmZtJ+AsBOszAazsAA+v9T2Mk0MC+7vw6hjdFpo OihgLTrIesf0g8gr8xGO/VQO3kW0aSrY9YrK1Dn2SCY5xWun3cBX5yCpaz5VGEV0r8fPI1Ay RAXAA4BRU2evceV+4KicPNipfofC86oLrpK7xmMzRmBZRonabbqZv2WoPN9gnI3jM0IGuvCb c0EbzYpdA7HfxBEJlYQDtQ5gfusgX78NTZfrTp5p4JuuzSVkFM3j+OrbIe9lt+iHK25mm6Co W3L5SLhCwwyP92D0zuVtHmrg4cjmAuiAthMSuboraQCbFu772oZMjJJEmmAufiYkkOmZYwAc 3cqw397xUQ13AnxJjXnZDWorXjBshMCVt54F+wh9BrL2qfS+xyeBGUPUnhGctNOnM08SCEu1 1SJt8j0HjEpu7qQIVqC8p+EoDX0PjIaRUcZYisJSwYt5MHuposoglTIVNkLLUKuptj8GDW1z zXUqiE73+kXlZRTi/j9+k3biTWxoJSPVhQy+gjcQmOi6EV+eZKhYIurr1Pc6J6sMbqkc7VIh 1Bc8+D20QzEJcjlePClKAnVIIyU2g==
- Ironport-hdrordr: A9a23:WdARgai80O4bhLr08jWTsr26anBQXgwji2hC6mlwRA09TyXBrb HWoBwavSWUtN9jYgBZpTngAtj+fZqyz+8R3WB8B9iftUzdyQ2VxeJZnPXfKl/baknDH4dmvM 8KGcUTNDSzNykcsS+T2njILz9K+rm6GdWT9IXjJgBWPGJXgs9bgTuRQTzraXGeDDM2f6bQX/ Knl7p6TyzJQwVrUi2UPAh4Y9T+
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
OpenBSD 7.3 will unconditionally access HWCR if the TSC is reported as
Invariant, and it will then attempt to also unconditionally access PSTATE0 if
HWCR.TscFreqSel is set (currently the case on Xen).
The motivation for exposing HWCR.TscFreqSel was to avoid warning messages from
Linux. It has been agreed that Linux should be changed instead to not
complaint about missing HWCR.TscFreqSel when running virtualized.
The relation between HWCR.TscFreqSel and PSTATE0 is not clearly written down in
the PPR, but it's natural for OSes to attempt to fetch the P0 frequency if the
TSC is stated to increment at the P0 frequency.
Exposing PSTATEn (PSTATE0 at least) with all zeroes is not a suitable solution
because the PstateEn bit is read-write, and OSes could legitimately attempt to
set PstateEn=1 which Xen couldn't handle.
Furthermore, the TscFreqSel bit is model specific and was never safe to expose
like this in the first place. At a minimum it should have had a toolstack
adjustment to know not to migrate such a VM.
Therefore, simply remove the bit. Note the HWCR itself is an architectural
register, and does need to be accessible by the guest. Since HWCR contains
both architectural and non-architectural bits, going forward care must be taken
to assert the exposed value is correct on newer CPU families.
Reported-by: Solène Rapenne <solene@xxxxxxxxxxx>
Link: https://github.com/QubesOS/qubes-issues/issues/8502
Fixes: 14b95b3b8546 ('x86/AMD: expose HWCR.TscFreqSel to guests')
Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
---
Changes since v2:
- Adjust commit message.
---
xen/arch/x86/msr.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 3f0450259cdf..c33dc78cd8f6 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -240,8 +240,7 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
case MSR_K8_HWCR:
if ( !(cp->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) )
goto gp_fault;
- *val = get_cpu_family(cp->basic.raw_fms, NULL, NULL) >= 0x10
- ? K8_HWCR_TSC_FREQ_SEL : 0;
+ *val = 0;
break;
case MSR_VIRT_SPEC_CTRL:
--
2.42.0
|
