[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 02/22] x86/msr: implement MSR_SMI_COUNT for Dom0 on Intel


  • To: Edwin Török <edwin.torok@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 30 Oct 2023 17:20:58 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=w6geNRyVnAZFztF+B5xdlA8rKGH2UDWHlouDjL9Omh8=; b=KzWUAX+Go9c2caz2Nbzoah303ZluQpSOQ/qYsJFp1DiFzQzJSXWROiTmhiEnd/WT45NtWXBHmcm5oJFSdkm5lEDOvPfHEAko/wCd6U3/lvzU16FF9euivLVVnFbGMv0OQvpWJXKwqXigckXcQHqXza1iwMtevW9v3gec/sg5+A4wOO2kFUndVoKSLJ0lOnhgs5uzJN7VRnFlfpOJU850/iywf4dPyOKtajoZG/6hjBIq0s3lc3k5wM0d7Mskktif+buSdKJAFIN1yHjDh2jzLUEciQLH+7YC054RiDnJ2VHsvV9YmxdyBgHTRu9DFfVuvXePz0xY9Wyu5fFyFMLeJw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dFyZniiLYdvqh7VA8FG8mWZrGHT9DoIvJEreo1RslKY+qC1EfUv29hR1exON+dA4coM2MaFfQzAPKysbqLc3cpTYfAo+5Fe75zCTLS+VO/NsVmHxan9+YPV9rC059AaiLHbxvlGbUhinPO0tFpjQ4qyeoeBAegKKLXoxtNmBDFyzvUq/mZyEcYDXb2IwtQZDGpXW0mQINB/zmwTlrjrnGYzLMgJ8xZYDMvlbSoTMV67PeQus4k06dmuYcVMxtnfXjchSPpCtmkLuQB0V3/aRyBtOvvtF0pdcpz2OuHTMCkDcPH4xqxrGY+VWQl4EzySRPFsm1+h6ltWeaJ+kbG+ZwA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Edwin Török <edvin.torok@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 30 Oct 2023 16:21:05 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 25.10.2023 21:29, Edwin Török wrote:
> Dom0 should always be able to read this MSR: it is useful when
> investigating performance issues in production.

While I'm not outright opposed, I'm also not convinced. At the very least
...

> Although the count is Thread scoped, in practice all cores were observed
> to return the same count (perhaps due to implementation details of SMM),
> so do not require the cpu to be pinned in order to read it.

... this, even if matching your observations, is going to be properly
misleading in case counts end up diverging.

> This MSR exists on Intel since Nehalem.
> 
> Backport: 4.15+

If this was a backporting candidate, I think a Fixes: tag would need
to indicate what's being fixed here. Otherwise this is merely a new
feature.

> --- a/xen/arch/x86/include/asm/msr-index.h
> +++ b/xen/arch/x86/include/asm/msr-index.h
> @@ -641,6 +641,9 @@
>  #define MSR_NHL_LBR_SELECT           0x000001c8
>  #define MSR_NHL_LASTBRANCH_TOS               0x000001c9
>  
> +/* Nehalem and newer other MSRs */
> +#define MSR_SMI_COUNT                       0x00000034

See my comment on the other patch regarding additions here.

> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -139,6 +139,13 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t 
> *val)
>          *val = msrs->misc_features_enables.raw;
>          break;
>  
> +    case MSR_SMI_COUNT:
> +        if ( cp->x86_vendor != X86_VENDOR_INTEL )
> +            goto gp_fault;
> +        if ( is_hardware_domain(d) && !rdmsr_safe(msr, *val) )
> +            break;
> +        return X86EMUL_UNHANDLEABLE;

Why #GP for non-Intel but UNHANDLEABLE for DomU?

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.