From nobody Mon May 6 22:39:42 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=suse.com ARC-Seal: i=1; a=rsa-sha256; t=1615535703; cv=none; d=zohomail.com; s=zohoarc; b=W20ND6W4hGUiw+r8DC0IQnm/2HTXa2n91gPutqKGlqohtkraF2SbiOAvS3qc4SE1IzEdmkrUyLQ11oxT45E9DYq5wpUzYXkpzreq4Jq2gISxArx24/HxBX7O34JwroQO/GeQXms9Hh1y9pOqJVarqbnxVWNS7fafJuctgTaYEtM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1615535703; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=ZvlKusSXHPm7ZHxV0KpYOFnqvBFQX3cO0pgsQ+grOaw=; b=YeRC4xur7FeFbfP0D2MdysPv2bv4kla6hnw/B4h7zj45JpTVCEHahMeziEYkRk4mFKZK/mrBSgnmvNelOrGClYom17hGHVSmakLr+nTj5geW9IJexCYumFQ/2ahFfKV7iT9/M4ruYzk7UyGFAPeEq6fufpfruUywJ+QWFKi8noM= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1615535703345870.2840313516363; Thu, 11 Mar 2021 23:55:03 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.96870.183717 (Exim 4.92) (envelope-from ) id 1lKcdE-0007D4-EE; Fri, 12 Mar 2021 07:54:48 +0000 Received: by outflank-mailman (output) from mailman id 96870.183717; Fri, 12 Mar 2021 07:54:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lKcdE-0007Cx-BH; Fri, 12 Mar 2021 07:54:48 +0000 Received: by outflank-mailman (input) for mailman id 96870; Fri, 12 Mar 2021 07:54:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lKcdD-0007Cq-3h for xen-devel@lists.xenproject.org; Fri, 12 Mar 2021 07:54:47 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 13a0468d-786a-44ed-ac97-7dd026bcde6c; Fri, 12 Mar 2021 07:54:46 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 5E509AE5C; Fri, 12 Mar 2021 07:54:45 +0000 (UTC) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 13a0468d-786a-44ed-ac97-7dd026bcde6c X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1615535685; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZvlKusSXHPm7ZHxV0KpYOFnqvBFQX3cO0pgsQ+grOaw=; b=gJRvwZ9/oXAkoWXNHmCWHY3833IWChRX6+a5cMQGHPYMvv6+SwiXaWYZ0AUi/OsEuRzu+T yVz7NPAzfUcP3YGc3F3wGNvfcGonRYgc0BuaV1+x8Q1NLhFtDmoWbTP54HtGFteaH2t9qp geewSvja4HoYtKJUKsdHs12uHhgDDjI= Subject: [PATCH v3 1/2][4.15] x86/PV: conditionally avoid raising #GP for early guest MSR reads From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Ian Jackson References: <7a84bc56-0045-2111-6888-8db830335ad1@suse.com> Message-ID: <90f87aa8-09da-1453-bd82-c722465c2881@suse.com> Date: Fri, 12 Mar 2021 08:54:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <7a84bc56-0045-2111-6888-8db830335ad1@suse.com> Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @suse.com) Content-Type: text/plain; charset="utf-8" Prior to 4.15 Linux, when running in PV mode, did not install a #GP handler early enough to cover for example the rdmsrl_safe() of MSR_K8_TSEG_ADDR in bsp_init_amd() (not to speak of the unguarded read of MSR_K7_HWCR later in the same function). The respective change (42b3a4cb5609 "x86/xen: Support early interrupts in xen pv guests") was backported to 4.14, but no further - presumably since it wasn't really easy because of other dependencies. Therefore, to prevent our change in the handling of guest MSR accesses to render PV Linux 4.13 and older unusable on at least AMD systems, make the raising of #GP on this paths conditional upon the guest having installed a handler, provided of course the MSR can be read in the first place (we would have raised #GP in that case even before). Producing zero for reads isn't necessarily correct and may trip code trying to detect presence of MSRs early, but since such detection logic won't work without a #GP handler anyway, this ought to be a fair workaround. Signed-off-by: Jan Beulich Release-Acked-by: Ian Jackson Reviewed-by: Roger Pau Monn=C3=A9 --- (projected v4: re-base over Roger's change) v3: Use temporary variable for probing. Document the behavior (in a public header, for the lack of a better place). v2: Probe MSR read. Exclude hypervisor range. Avoid issuing two log messages (in debug builds). Don't alter WRMSR behavior. --- While I didn't myself observe or find similar WRMSR side issues, I'm nevertheless not convinced we can get away without also making the WRMSR path somewhat more permissive again, e.g. tolerating attempts to set bits which are already set. But of course this would require keeping in sync for which MSRs we "fake" reads, as then a kernel attempt to set a bit may also appear as an attempt to clear others (because of the zero value that we gave it for the read). Roger validly points out that making behavior dependent upon MSR values has its own downsides, so simply depending on MSR readability is another option (with, in turn, its own undesirable effects, e.g. for write-only MSRs). --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -874,7 +874,8 @@ static int read_msr(unsigned int reg, ui struct vcpu *curr =3D current; const struct domain *currd =3D curr->domain; const struct cpuid_policy *cp =3D currd->arch.cpuid; - bool vpmu_msr =3D false; + bool vpmu_msr =3D false, warn =3D false; + uint64_t tmp; int ret; =20 if ( (ret =3D guest_rdmsr(curr, reg, val)) !=3D X86EMUL_UNHANDLEABLE ) @@ -882,7 +883,7 @@ static int read_msr(unsigned int reg, ui if ( ret =3D=3D X86EMUL_EXCEPTION ) x86_emul_hw_exception(TRAP_gp_fault, 0, ctxt); =20 - return ret; + goto done; } =20 switch ( reg ) @@ -986,7 +987,7 @@ static int read_msr(unsigned int reg, ui } /* fall through */ default: - gdprintk(XENLOG_WARNING, "RDMSR 0x%08x unimplemented\n", reg); + warn =3D true; break; =20 normal: @@ -995,7 +996,19 @@ static int read_msr(unsigned int reg, ui return X86EMUL_OKAY; } =20 - return X86EMUL_UNHANDLEABLE; + done: + if ( ret !=3D X86EMUL_OKAY && !curr->arch.pv.trap_ctxt[X86_EXC_GP].add= ress && + (reg >> 16) !=3D 0x4000 && !rdmsr_safe(reg, tmp) ) + { + gprintk(XENLOG_WARNING, "faking RDMSR 0x%08x\n", reg); + *val =3D 0; + x86_emul_reset_event(ctxt); + ret =3D X86EMUL_OKAY; + } + else if ( warn ) + gdprintk(XENLOG_WARNING, "RDMSR 0x%08x unimplemented\n", reg); + + return ret; } =20 static int write_msr(unsigned int reg, uint64_t val, --- a/xen/include/public/arch-x86/xen.h +++ b/xen/include/public/arch-x86/xen.h @@ -143,6 +143,12 @@ typedef unsigned long xen_ulong_t; * Level =3D=3D 1: Kernel may enter * Level =3D=3D 2: Kernel may enter * Level =3D=3D 3: Everyone may enter + * + * Note: For compatibility with kernels not setting up exception handlers + * early enough, Xen will avoid trying to inject #GP (and hence crash + * the domain) when an RDMSR would require this, but no handler was + * set yet. The precise conditions are implementation specific, and + * new code shouldn't rely on such behavior anyway. */ #define TI_GET_DPL(_ti) ((_ti)->flags & 3) #define TI_GET_IF(_ti) ((_ti)->flags & 4) From nobody Mon May 6 22:39:42 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=suse.com ARC-Seal: i=1; a=rsa-sha256; t=1615535742; cv=none; d=zohomail.com; s=zohoarc; b=EsV40/IPkdMsXx5WO6tcs/1EZq1bQsHPsdfu10KSo9yEdCOswfST6gREBoy/8mv27v7CQyrd2ESlXsoE0kdu52yrZwSahc7Hyklran+6ra9d6Dhevlt8BpxZYLR1mCySMShzc0+bISVaXEYsl+8ECu7+K25d0zxGqbFZ4t2wipQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1615535742; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=QFrMh+sBcKyoQb7P1wDYHd/74ZilGORQiERspE6maW0=; b=R9g33JXdtjQZtUR+Dt4DnGBRtf7OLBm4VtHzf9T/8coUBrlOBdRkefYa5KdBGaHH1N5q5MaUpvp0nrggegqV3ewzheFHePWu2ScqRFC/j91+W/4tn7BTtZgnENWSlbPXXNOfuEWrV8nIPn51NGP5oK9WhNtO85u+apDy1MPd7/A= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1615535742280541.5180471545866; Thu, 11 Mar 2021 23:55:42 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.96873.183729 (Exim 4.92) (envelope-from ) id 1lKcds-0007JC-OF; Fri, 12 Mar 2021 07:55:28 +0000 Received: by outflank-mailman (output) from mailman id 96873.183729; Fri, 12 Mar 2021 07:55:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lKcds-0007J5-Ke; Fri, 12 Mar 2021 07:55:28 +0000 Received: by outflank-mailman (input) for mailman id 96873; Fri, 12 Mar 2021 07:55:27 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lKcdr-0007Iw-QL for xen-devel@lists.xenproject.org; Fri, 12 Mar 2021 07:55:27 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0a0919ba-7553-4536-bdf4-56da87783299; Fri, 12 Mar 2021 07:55:27 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 77D18AEBD; Fri, 12 Mar 2021 07:55:26 +0000 (UTC) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0a0919ba-7553-4536-bdf4-56da87783299 X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1615535726; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QFrMh+sBcKyoQb7P1wDYHd/74ZilGORQiERspE6maW0=; b=KtRStRZOrHCb5Rt5wy5ejseMiiAj5FHplLDzGS073uFJHjNfYG35dR0ItdR1XSDeeAfg4D SrEhhS7/lar4n3MPM+bPdS2SQrYX+WW5atT61RjslCXNi0w5Nn+m24Abvt2sHjocRbEGrP SO14KwmWzHMIRYoo/cNfUl7oGqAUpdU= Subject: [PATCH v3 2/2][4.15] x86/AMD: expose HWCR.TscFreqSel to guests From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Ian Jackson References: <7a84bc56-0045-2111-6888-8db830335ad1@suse.com> Message-ID: <414cceb7-003b-527d-7472-447be325dc14@suse.com> Date: Fri, 12 Mar 2021 08:55:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <7a84bc56-0045-2111-6888-8db830335ad1@suse.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @suse.com) Linux has been warning ("firmware bug") about this bit being clear for a long time. While writable in older hardware it has been readonly on more than just most recent hardware. For simplicitly report it always set (if anything we may want to log the issue ourselves if it turns out to be clear on older hardware) on CPU families 10h and up (in family 0fh the bit is part of a larger field of different purpose). Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monn=C3=A9 --- v3: Report 0 for Fam0F. v2: New. --- There are likely more bits worthwhile to expose, but for about every one of them there would be the risk of a lengthy discussion, as there are clear downsides to exposing such information. The more that it would be tbd whether the hardware values should be surfaced, and if so what should happen when the guest gets migrated. The main risk with making the read not fault here is that guests might imply they can also write this MSR then. --- a/xen/arch/x86/msr.c +++ b/xen/arch/x86/msr.c @@ -315,6 +315,13 @@ int guest_rdmsr(struct vcpu *v, uint32_t *val =3D msrs->tsc_aux; break; =20 + case MSR_K8_HWCR: + if ( !(cp->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) ) + goto gp_fault; + *val =3D get_cpu_family(cp->basic.raw_fms, NULL, NULL) >=3D 0x10 + ? K8_HWCR_TSC_FREQ_SEL : 0; + break; + case MSR_AMD64_DE_CFG: if ( !(cp->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) ) goto gp_fault; --- a/xen/include/asm-x86/msr-index.h +++ b/xen/include/asm-x86/msr-index.h @@ -287,6 +287,8 @@ =20 #define MSR_K7_HWCR 0xc0010015 #define MSR_K8_HWCR 0xc0010015 +#define K8_HWCR_TSC_FREQ_SEL (1ULL << 24) + #define MSR_K7_FID_VID_CTL 0xc0010041 #define MSR_K7_FID_VID_STATUS 0xc0010042 #define MSR_K8_PSTATE_LIMIT 0xc0010061