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

Re: [PATCH 6/8] x86: Derive XEN_MSR_PAT from its individual entries


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 6 Dec 2022 12:43:22 +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=pe7AtQLNKWCZhEndLa+dlDjAQaD97SDOwq53gWxLKlE=; b=Z3Kae0vtpkoMkJe46ZKl/Ctq7n181Aj5sQ2V3uRl+ElQks7pVyVeQRc1XYUOIPCCkm/9h32Vq1lpZT9vmq4dcvXuQ5nL1v0aKQOaZxUFI0pmJ7aY4lIOJ5kwb5zCEDWZIWnOo7ueN10ZMyS2n/7ZpYj2zvW1Ly7LdkxWqhmJm95pKxKtytoyWvzn/okA9fXhUs03Tck6rv6I12uACNxgniNn+TX+YuKF4Ahb0c6AlomCDRgr2bea2GFpnLsm60zvARIO6tVycZNUadgTGSFb/tGSjy4ll5Y8JWvcYK6wDFYdA30kATeR1jgonBvzeJSRzZByu1+39SKqaH4rLpKX8A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YPLBREYmmENATGioee0gmXtLZGlu9OS1pAnu+EJ4uhKUBneiIQiDO3JAkDh8DJrQbAdpawkkPwG6v13HPy7b7W/bi3cCEq8T4SDzKCSUuHKSlszqlsLm9Tk9+Xoj7m0P0jpgw+Dqb7t7ISKwfs84xzoPaA2HxRh0lBZMJH/I7WneVUtu5Y0ImC23mupcWevLcdAtdFP6HeJm0FdGM6L6enNI4o+47z6YkKdYyoNsXuEcRUrF7CRpE6Bp3lkCCWegItM/Qf+gYs4ZAJz+jO8M9tjFQto9V92CWdkrXMIKvBxe7+V11li6ejjoL503puUw69M7H6cmVMMdrkFjrQxZmw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>, "Tim (Xen.org)" <tim@xxxxxxx>, Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 06 Dec 2022 11:43:33 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 06.12.2022 12:32, Andrew Cooper wrote:
> On 06/12/2022 04:33, Demi Marie Obenour wrote:
>> --- a/xen/arch/x86/include/asm/processor.h
>> +++ b/xen/arch/x86/include/asm/processor.h
>> @@ -92,13 +92,33 @@
>>                            X86_EFLAGS_NT|X86_EFLAGS_DF|X86_EFLAGS_IF|    \
>>                            X86_EFLAGS_TF)
>>  
>> +/* Individual entries in IA32_CR_PAT */
>> +#define MSR_PAT_UC  _AC(0x00, ULL)
>> +#define MSR_PAT_WC  _AC(0x01, ULL)
>> +#define MSR_PAT_RESERVED_1  _AC(0x02, ULL)
>> +#define MSR_PAT_RESERVED_2  _AC(0x03, ULL)
>> +#define MSR_PAT_WT  _AC(0x04, ULL)
>> +#define MSR_PAT_WP  _AC(0x05, ULL)
>> +#define MSR_PAT_WB  _AC(0x06, ULL)
>> +#define MSR_PAT_UCM _AC(0x07, ULL)
> 
> This isn't really correct.  Constants for MSRs typically live in
> msr-index.h, but these are architectural x86 memory types.
> 
> These ought be
> 
> #define X86_MT_$X ...  (skipping the two reserved values)
> 
> in x86-defns.h, and the PAT_TYPE_*, MTRR_TYPE_* and EPT_EMT_* constants
> want removing.
> 
> There are two minor restrictions (EPT can't have UCM, MTRR can't have
> WC), but they are all operating in terms of architectural memory type
> values, and the code ought to reflect this.

The unavailability of UCM is common to MTRR and EPT's EMT. WC, at the
same time, is a valid type to use in both. Which makes sense - EMT
after all merely is replacing what otherwise is expressed by MTRRs.

Jan



 


Rackspace

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