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

Re: [PATCH v7 3/4] x86/mm: make code robust to future PAT changes


  • To: Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 9 Jan 2023 15:07:29 +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=8FY854m4Y8kLI3rt7W99QdLxDdx4/YRm4M4xbOMZp9M=; b=I7SUOeEVyHhhug+Dn//bs413ewH+qaiF5sFXU9Q+ikwMfQGvSlSmQcJjQEwcoo07xxH57B/+TGnIBVuvFTZYUA2G3xU+bU/G3LxPGDOVg10i/qwHkZAJLY1Vl3rp1/Y2TV/dF1Ozqbt9dEf0KgsMPHRqkU1sHQxdYgAwy+vcoQ9oByTIo5FnCC+XhNtiHt+fVssP0oe/d4KpioeE/g8pXf5OSQlFyTGPdrEbf8qiKROQ2pWZXsUHagBzJK5bI/LJZTmQ7uWTadJNpzK51Rq6mslz5b2eH1gkubKZ1yAICZZLWCUu2+GuIaamv7FzuGUBGFbtgCscV/BV9qwKKNlv4A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fwZI4rFMY0PVzOQo1uqO3xH05hO5Vqpk+NbIUBmOHcpU2wZ+4Ix4O7SN8/FcXKRpYT8R7WaaabmIC0ryx0IphKy6aJCFWNMUVXyq/rHWQ6Je3qD8SZub2LwgX3BWhen93ZEDsqmYvfcBRtUMoDPp5/j8DNTCw28ViGCbvqIbmoOIEdzy+9wgX4PzXfl19SJ4uYxPHiqpNNMcsIVV4R2YXjm48lN6hdqlXX1NoaVT4MULf7WNiqupEf3YNbXu445PBVuDYgonM9QxJcKeHWkbC8mfJ+Tk/o7XF3EXClUFxnNN/Lwwe/WKuhIlulXLWcWot/MZl6HzFBxz6D3Hh8+u4w==
  • 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>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 09 Jan 2023 14:07:49 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 07.01.2023 23:07, Demi Marie Obenour wrote:
> @@ -6412,6 +6414,100 @@ static void __init __maybe_unused 
> build_assertions(void)
>       * using different PATs will not work.
>       */
>      BUILD_BUG_ON(XEN_MSR_PAT != 0x050100070406ULL);
> +
> +    /*
> +     * _PAGE_WB must be zero.  Linux PV guests assume that _PAGE_WB will be
> +     * zero, and indeed Linux has a BUILD_BUG_ON validating that their 
> version
> +     * of _PAGE_WB *is* zero.  Furthermore, since _PAGE_WB is zero, it is 
> quite
> +     * likely to be omitted from various parts of Xen, and indeed L1 PTE
> +     * validation code checks that ((l1f & PAGE_CACHE_ATTRs) == 0), not
> +     * ((l1f & PAGE_CACHE_ATTRs) == _PAGE_WB).
> +     */
> +    BUILD_BUG_ON(_PAGE_WB);
> +
> +    /* _PAGE_RSVD_1 must be less than _PAGE_RSVD_2 */
> +    BUILD_BUG_ON(_PAGE_RSVD_1 >= _PAGE_RSVD_2);
> +
> +#define PAT_ENTRY(v)                                                         
>   \
> +    (BUILD_BUG_ON_ZERO(((v) < 0) || ((v) > 7)) +                             
>   \
> +     (0xFF & (XEN_MSR_PAT >> (8 * (v)))))
> +
> +    /* Validate at compile-time that v is a valid value for a PAT entry */
> +#define CHECK_PAT_ENTRY_VALUE(v)                                             
>   \
> +    BUILD_BUG_ON((v) > X86_NUM_MT || (v) == X86_MT_RSVD_2 ||                 
>   \
> +                 (v) == X86_MT_RSVD_3)
> +
> +    /* Validate at compile-time that PAT entry v is valid */
> +#define CHECK_PAT_ENTRY(v) CHECK_PAT_ENTRY_VALUE(PAT_ENTRY(v))
> +
> +    /*
> +     * If one of these trips, the corresponding entry in XEN_MSR_PAT is 
> invalid.
> +     * This would cause Xen to crash (with #GP) at startup.
> +     */
> +    CHECK_PAT_ENTRY(0);
> +    CHECK_PAT_ENTRY(1);
> +    CHECK_PAT_ENTRY(2);
> +    CHECK_PAT_ENTRY(3);
> +    CHECK_PAT_ENTRY(4);
> +    CHECK_PAT_ENTRY(5);
> +    CHECK_PAT_ENTRY(6);
> +    CHECK_PAT_ENTRY(7);
> +
> +    /* Macro version of pte_flags_to_cacheattr(), for use in BUILD_BUG_ON()s 
> */
> +#define PTE_FLAGS_TO_CACHEATTR(pte_value)                                    
>   \
> +    /* Check that the _PAGE_* macros only use bits from PAGE_CACHE_ATTRS */  
>   \
> +    (BUILD_BUG_ON_ZERO(((pte_value) & PAGE_CACHE_ATTRS) != (pte_value)) |    
>   \

Slightly cheaper as BUILD_BUG_ON_ZERO((pte_value) & ~PAGE_CACHE_ATTRS)?

> +     (((pte_value) & _PAGE_PAT) >> 5) |                                      
>   \
> +     (((pte_value) & (_PAGE_PCD | _PAGE_PWT)) >> 3))
> +
> +    CHECK_PAT_ENTRY(PTE_FLAGS_TO_CACHEATTR(_PAGE_RSVD_1));
> +    CHECK_PAT_ENTRY(PTE_FLAGS_TO_CACHEATTR(_PAGE_RSVD_2));

What do these two check that the 8 instances above don't already check?

> +#define PAT_ENTRY_FROM_FLAGS(x) PAT_ENTRY(PTE_FLAGS_TO_CACHEATTR(x))
> +
> +    /* Validate at compile time that X does not duplicate a smaller PAT 
> entry */
> +#define CHECK_DUPLICATE_ENTRY(x, y)                                          
>   \
> +    BUILD_BUG_ON((x) >= (y) &&                                               
>   \
> +                 (PAT_ENTRY_FROM_FLAGS(x) == PAT_ENTRY_FROM_FLAGS(y)))

Imo nothing says that the reserved entries come last. I'm therefore not
convinced of the usefulness of the two uses of this macro.

> +    /* Check that a PAT-related _PAGE_* macro is correct */
> +#define CHECK_PAGE_VALUE(page_value) do {                                    
>   \
> +    /* Check that the _PAGE_* macros only use bits from PAGE_CACHE_ATTRS */  
>   \
> +    BUILD_BUG_ON(((_PAGE_ ## page_value) & PAGE_CACHE_ATTRS) !=              
>   \
> +                 (_PAGE_ ## page_value));                                    
>   \
> +    /* Check that the _PAGE_* are consistent with XEN_MSR_PAT */             
>   \
> +    BUILD_BUG_ON(PAT_ENTRY(PTE_FLAGS_TO_CACHEATTR(_PAGE_ ## page_value)) !=  
>   \
> +                 (X86_MT_ ## page_value));                                   
>   \
> +    case _PAGE_ ## page_value:; /* ensure no duplicate values */             
>   \

Wouldn't this better come first in the macro? The semicolon looks unnecessary
in any event.

> +    /*                                                                       
>   \
> +     * Check that the _PAGE_* entries do not duplicate a smaller reserved    
>   \
> +     * entry.                                                                
>   \
> +     */                                                                      
>   \
> +    CHECK_DUPLICATE_ENTRY(_PAGE_ ## page_value, _PAGE_RSVD_1);               
>   \
> +    CHECK_DUPLICATE_ENTRY(_PAGE_ ## page_value, _PAGE_RSVD_2);               
>   \
> +    CHECK_PAT_ENTRY(PTE_FLAGS_TO_CACHEATTR(_PAGE_ ## page_value));           
>   \
> +} while ( false )
> +
> +    /*
> +     * If one of these trips, the corresponding _PAGE_* macro is inconsistent
> +     * with XEN_MSR_PAT.  This would cause Xen to use incorrect cacheability
> +     * flags, with results that are unknown and possibly harmful.
> +     */
> +    switch (0) {

Nit: Style.

> +    CHECK_PAGE_VALUE(WT);
> +    CHECK_PAGE_VALUE(WB);
> +    CHECK_PAGE_VALUE(WC);
> +    CHECK_PAGE_VALUE(UC);
> +    CHECK_PAGE_VALUE(UCM);
> +    CHECK_PAGE_VALUE(WP);

All of these are lacking "break" and hence are liable to trigger static checker
warnings.

> +    case _PAGE_RSVD_1:
> +    case _PAGE_RSVD_2:
> +        break;
> +    }
> +#undef CHECK_PAT_ENTRY
> +#undef CHECK_PAT_ENTRY_VALUE
> +#undef CHECK_PAGE_VALUE
> +#undef PAGE_FLAGS_TO_CACHEATTR

PTE_FLAGS_TO_CACHEATTR?

> +#undef PAT_ENTRY

You also #define more than these 5 macros now (but as per above e.g.
CHECK_DUPLICATE_ENTRY() may go away again).

Jan



 


Rackspace

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