From patchwork Sat Oct 22 15:51:12 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlo Nonato X-Patchwork-Id: 13016008 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 75991FA3741 for ; Sat, 22 Oct 2022 15:51:59 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.428408.678495 (Exim 4.92) (envelope-from ) id 1omGml-0002Z1-3V; Sat, 22 Oct 2022 15:51:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 428408.678495; Sat, 22 Oct 2022 15:51:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1omGmk-0002Ys-Tw; Sat, 22 Oct 2022 15:51:42 +0000 Received: by outflank-mailman (input) for mailman id 428408; Sat, 22 Oct 2022 15:51:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1omGmj-0002Ir-90 for xen-devel@lists.xenproject.org; Sat, 22 Oct 2022 15:51:41 +0000 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [2a00:1450:4864:20::52c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6993cab8-5221-11ed-91b5-6bf2151ebd3b; Sat, 22 Oct 2022 17:51:39 +0200 (CEST) Received: by mail-ed1-x52c.google.com with SMTP id u21so16364669edi.9 for ; Sat, 22 Oct 2022 08:51:37 -0700 (PDT) Received: from carlo-ubuntu.home (62-11-205-162.dialup.tiscali.it. [62.11.205.162]) by smtp.gmail.com with ESMTPSA id z61-20020a509e43000000b00461816beef9sm894623ede.14.2022.10.22.08.51.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Oct 2022 08:51:36 -0700 (PDT) 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: 6993cab8-5221-11ed-91b5-6bf2151ebd3b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ninxl7zeTOLhM6GAnaxyPElcqi5G7SjegJNvFx79Nbc=; b=a7yjZpmIh+NPgVpmQ4LOTpYlC+ajUZTCNned8FpjQ6Bfl88T8wOaM5iXM0tnN+kYGZ X/C1sDj25h5P/QGrHHqK+XxoBiHnQ4stum+01cNp+AGCOYqbw5C1t4k01h7RFAoSpsRr vrRTixpBo7j1TmUT87JECol3ONuirv5uSmPmagr/B4nsY8jNtDnemjijmOWsiQ/Tbwdp nn3AsPbv+d+BsNhkR4HLw008peu6vUrbLXsFvjn64WncHwLyBfTbqxwEVFMuqHr7ojin bUMTNTagGWBbV9xrxCnClgaS/9X5icVARl9Oyxyz18fVYtD/idoOg2lXQmlnqmhMAfia lSAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ninxl7zeTOLhM6GAnaxyPElcqi5G7SjegJNvFx79Nbc=; b=JfQusgq68//wwYimQuKnQ7JfMWCW14cRdUUgYCJBRpJR3UfUBRtCfA3YMi6L6xUt28 NVwKOadDjeh9gahLKC7w6+YJSgPQ/NsHSKizhX0HJIJdAdn6nSMHLmppWrZ06w0sz5CR 4xOgIOjJKq7QXfLk03AsGWSuOysWdFz6rd0FvsD2gtyc1u/e5SUbDKK+fItIRQPOVXIf 2LXod2DRSELhRsx3RxkP7KFqm6dal7ToFKCNS3SXGp1PXvp0+EIZr720wLPpgMavxaY7 OJo5lCRy3pCLRfUfyD37uiUW0cGG3d6sCeCI1lyWKmNMz2nbTTMcH810yLIMOl7/ACLa GlEA== X-Gm-Message-State: ACrzQf0UuGCsi7+Sljll/YUdiEcuqD8jIV6avCJ2xHztALlFJ0mOdf4/ +y2LscXU3RPsNxSKwnbKvnekEbGynyIBBA== X-Google-Smtp-Source: AMsMyM7i71NKIiUcFaiGbkODGKyUICgpneseUE2cch5z2qksy95TN57zoUZBaQnk2RokXBoBoXiFZg== X-Received: by 2002:a17:907:6d84:b0:78d:f2b0:14c8 with SMTP id sb4-20020a1709076d8400b0078df2b014c8mr19729711ejc.749.1666453896749; Sat, 22 Oct 2022 08:51:36 -0700 (PDT) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: marco.solieri@unimore.it, andrea.bastoni@minervasys.tech, lucmiccio@gmail.com, Carlo Nonato , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu , Marco Solieri Subject: [PATCH v3 1/9] xen/arm: add cache coloring initialization Date: Sat, 22 Oct 2022 17:51:12 +0200 Message-Id: <20221022155120.7000-2-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221022155120.7000-1-carlo.nonato@minervasys.tech> References: <20221022155120.7000-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 This commit adds the cache coloring support initialization, Kconfig options, command line parameters and the initial documentation. The initialization consists of an auto probing of the cache layout necessary to retrieve the LLC way size which is used to compute the number of available colors. The Dom0 colors are then initialized with default colors (all available ones) if not provided from the command line, and they are checked for bad configuration. It also adds a debug-key to dump general cache coloring info. This includes LLC way size, total available colors and the mask used to extract colors from physical addresses. Based on original work from: Luca Miccio Signed-off-by: Carlo Nonato Signed-off-by: Marco Solieri --- v3: - HAS_CACHE_COLORING config added - fixed CONFIG_MAX_CACHE_COLORS range and explained why such range - __ro_after_init for coloring globals - stub functions in case of coloring disabled, in coloring.c (like in v1) - check number of colors in range [2, CONFIG_MAX_CACHE_COLORS] at runtime - LLC way size and number of colors must be a power of 2 (explained in docs and checked at runtime) --- docs/misc/arm/cache-coloring.rst | 135 +++++++++++++++ docs/misc/xen-command-line.pandoc | 26 +++ xen/arch/arm/Kconfig | 22 +++ xen/arch/arm/Makefile | 1 + xen/arch/arm/coloring.c | 243 +++++++++++++++++++++++++++ xen/arch/arm/include/asm/coloring.h | 38 +++++ xen/arch/arm/include/asm/processor.h | 16 ++ xen/arch/arm/setup.c | 7 + xen/common/Kconfig | 3 + 9 files changed, 491 insertions(+) create mode 100644 docs/misc/arm/cache-coloring.rst create mode 100644 xen/arch/arm/coloring.c create mode 100644 xen/arch/arm/include/asm/coloring.h diff --git a/docs/misc/arm/cache-coloring.rst b/docs/misc/arm/cache-coloring.rst new file mode 100644 index 0000000000..b0f9a2e917 --- /dev/null +++ b/docs/misc/arm/cache-coloring.rst @@ -0,0 +1,135 @@ +Xen cache coloring user guide +============================= + +The cache coloring support in Xen allows to reserve Last Level Cache (LLC) +partition for Dom0, DomUs and Xen itself. Currently only ARM64 is supported. + +In order to enable and use it, few steps are needed. + +- Enable expert mode in Xen configuration file. + + CONFIG_EXPERT=y +- Enable cache coloring in Xen configuration file. + + CONFIG_CACHE_COLORING=y +- If needed, change the maximum number of colors in Xen configuration file + (refer to menuconfig help for value meaning and when it should be changed). + + CONFIG_MAX_CACHE_COLORS= +- Assign colors to Dom0 using the `Color selection format`_ (see + `Coloring parameters`_ for more documentation pointers). + +Background +********** + +Cache hierarchy of a modern multi-core CPU typically has first levels dedicated +to each core (hence using multiple cache units), while the last level is shared +among all of them. Such configuration implies that memory operations on one +core (e.g. running a DomU) are able to generate interference on another core +(e.g .hosting another DomU). Cache coloring allows eliminating this +mutual interference, and thus guaranteeing higher and more predictable +performances for memory accesses. +The key concept underlying cache coloring is a fragmentation of the memory +space into a set of sub-spaces called colors that are mapped to disjoint cache +partitions. Technically, the whole memory space is first divided into a number +of subsequent regions. Then each region is in turn divided into a number of +subsequent sub-colors. The generic i-th color is then obtained by all the +i-th sub-colors in each region. + +.. raw:: html + + 
+                            Region j            Region j+1
+                .....................   ............
+                .                     . .
+                .                       .
+            _ _ _______________ _ _____________________ _ _
+                |     |     |     |     |     |     |
+                | c_0 | c_1 |     | c_n | c_0 | c_1 |
+           _ _ _|_____|_____|_ _ _|_____|_____|_____|_ _ _
+                    :                       :
+                    :                       :...         ... .
+                    :                            color 0
+                    :...........................         ... .
+                                                :
+          . . ..................................:
+
+ +There are two pragmatic lesson to be learnt. + +1. If one wants to avoid cache interference between two domains, different + colors needs to be used for their memory. + +2. Color assignment must privilege contiguity in the partitioning. E.g., + assigning colors (0,1) to domain I and (2,3) to domain J is better than + assigning colors (0,2) to I and (1,3) to J. + +How to compute the number of colors +*********************************** + +To compute the number of available colors for a specific platform, the size of +an LLC way and the page size used by Xen must be known. The first parameter can +be found in the processor manual or can be also computed dividing the total +cache size by the number of its ways. The second parameter is the minimum amount +of memory that can be mapped by the hypervisor, thus dividing the way size by +the page size, the number of total cache partitions is found. So for example, +an Arm Cortex-A53 with a 16-ways associative 1 MiB LLC, can isolate up to 16 +colors when pages are 4 KiB in size. + +Cache layout is probed automatically by Xen itself, but a possibility to +manually set the way size it's left for the user to overcome failing situations +or for debugging/testing purposes. See `Coloring parameters`_ section for more +information on that. + +Colors selection format +*********************** + +Regardless of the memory pool that has to be colored (Xen, Dom0/DomUs), +the color selection can be expressed using the same syntax. In particular a +comma-separated list of colors or ranges of colors is used. +Ranges are hyphen-separated intervals (such as `0-4`) and are inclusive on both +sides. + +Note that: + - no spaces are allowed between values. + - no overlapping ranges or duplicated colors are allowed. + - values must be written in ascending order. + +Examples: + ++---------------------+-----------------------------------+ +|**Configuration** |**Actual selection** | ++---------------------+-----------------------------------+ +| 1-2,5-8 | [1, 2, 5, 6, 7, 8] | ++---------------------+-----------------------------------+ +| 4-8,10,11,12 | [4, 5, 6, 7, 8, 10, 11, 12] | ++---------------------+-----------------------------------+ +| 0 | [0] | ++---------------------+-----------------------------------+ + +Coloring parameters +******************* + +LLC way size (as previously discussed) and Dom0 colors can be set using the +appropriate command line parameters. See the relevant documentation in +"docs/misc/xen-command-line.pandoc". + +Known issues and limitations +**************************** + +Cache coloring is intended only for embedded systems +#################################################### + +The current implementation aims to satisfy the need of predictability in +embedded systems with small amount of memory to be managed in a colored way. +Given that, some shortcuts are taken in the development. Expect worse +performances on larger systems. + +The maximum number of colors supported is 32768 +############################################### + +The upper bound of the CONFIG_MAX_CACHE_COLORS range (which is an upper bound +too) is set to 2^15 = 32768 colors because of some limitation on the domain +configuration structure size used in domain creation. "uint16_t" is the biggest +integer type that fit the constraint and 2^15 is the biggest power of 2 it can +easily represent. This value is big enough for the generic case, though. diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 68389843b2..3f04414134 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -903,6 +903,14 @@ Controls for the dom0 IOMMU setup. Incorrect use of this option may result in a malfunctioning system. +### dom0-colors (arm64) +> `= List of [ | - ]` + +> Default: `All available colors` + +Specify dom0 color configuration. If the parameter is not set, all available +colors are chosen and the user is warned on Xen's serial console. + ### dom0_ioports_disable (x86) > `= List of -` @@ -1645,6 +1653,24 @@ This option is intended for debugging purposes only. Enable MSR_DEBUGCTL.LBR in hypervisor context to be able to dump the Last Interrupt/Exception To/From record with other registers. +### llc-way-size (arm64) +> `= ` + +> Default: `Obtained from the hardware` + +Specify the way size of the Last Level Cache. This parameter is only useful with +cache coloring support enabled. It is an optional, expert-only parameter and it +is used to calculate the number of available colors on the platform. It can be +obtained by dividing the total LLC size by the number of its associative ways. +By default, the value is automatically computed by probing the hardware, but in +case of specific needs, it can be manually set. Those include failing probing +and debugging/testing purposes so that it's possibile to emulate platforms with +different number of supported colors. +An important detail to highlight is that the current implementation of the +cache coloring technique requires the number of colors to be a power of 2, and +consequently, also the LLC way size must be so. A value that doesn't match this +requirement is aligned down to the previous power of 2. + ### loglvl > `= [/]` where level is `none | error | warning | info | debug | all` diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 1fe5faf847..c45a9c5917 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -9,6 +9,7 @@ config ARM_64 select 64BIT select ARM_EFI select HAS_FAST_MULTIPLY + select HAS_CACHE_COLORING config ARM def_bool y @@ -131,6 +132,27 @@ config ARM64_BTI Branch Target Identification support. This feature is not supported in Xen. +config CACHE_COLORING + bool "Last Level Cache (LLC) coloring" if EXPERT + depends on HAS_CACHE_COLORING + +config MAX_CACHE_COLORS + int "Maximum number of cache colors" + default 128 + range 2 32768 + depends on CACHE_COLORING + help + This config value is an upper bound for the actual number of cache colors + supported by the architecture. Xen preallocates this amount of cache + colors at boot. Refer to the documentation for how to compute the number + of colors supported by the platform. + The default value corresponds to an 8 MiB 16-ways LLC, which should be + more than what needed in the normal case. + The max value corresponds to a 2 GiB 16-ways LLC which should never be + reached. + Note that if, at any time, a color configuration with more colors than the + maximum is employed, an error is produced. + config TEE bool "Enable TEE mediators support (UNSUPPORTED)" if UNSUPPORTED default n diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index 4d076b278b..12940ba761 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -67,6 +67,7 @@ obj-$(CONFIG_SBSA_VUART_CONSOLE) += vpl011.o obj-y += vsmc.o obj-y += vpsci.o obj-y += vuart.o +obj-$(CONFIG_CACHE_COLORING) += coloring.o extra-y += xen.lds diff --git a/xen/arch/arm/coloring.c b/xen/arch/arm/coloring.c new file mode 100644 index 0000000000..36eea2d6c0 --- /dev/null +++ b/xen/arch/arm/coloring.c @@ -0,0 +1,243 @@ +/* + * xen/arch/arm/coloring.c + * + * Coloring support for ARM + * + * Copyright (C) 2019 Xilinx Inc. + * + * Authors: + * Luca Miccio + * Carlo Nonato + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see . + */ +#include +#include +#include +#include +#include + +#include +#include +#include + +/* Size of an LLC way */ +static unsigned int __ro_after_init llc_way_size; +/* Number of colors available in the LLC */ +static unsigned int __ro_after_init max_colors = CONFIG_MAX_CACHE_COLORS; +/* Mask to retrieve coloring relevant bits */ +static uint64_t __ro_after_init addr_col_mask; + +#define addr_to_color(addr) (((addr) & addr_col_mask) >> PAGE_SHIFT) +#define addr_set_color(addr, color) (((addr) & ~addr_col_mask) \ + | ((color) << PAGE_SHIFT)) + +static unsigned int dom0_colors[CONFIG_MAX_CACHE_COLORS]; +static unsigned int dom0_num_colors; + +/* + * Parse the coloring configuration given in the buf string, following the + * syntax below. + * + * COLOR_CONFIGURATION ::= COLOR | RANGE,...,COLOR | RANGE + * RANGE ::= COLOR-COLOR + * + * Example: "0,2-6,15-16" represents the set of colors: 0,2,3,4,5,6,15,16. + */ +static int parse_color_config(const char *buf, unsigned int *colors, + unsigned int *num_colors) +{ + const char *s = buf; + + if ( !colors || !num_colors ) + return -EINVAL; + + while ( *s != '\0' ) + { + if ( *s != ',' ) + { + unsigned int color, start, end; + + start = simple_strtoul(s, &s, 0); + + if ( *s == '-' ) /* Range */ + { + s++; + end = simple_strtoul(s, &s, 0); + } + else /* Single value */ + end = start; + + if ( start > end || + *num_colors + end - start >= max_colors ) + return -EINVAL; + for ( color = start; color <= end; color++ ) + colors[(*num_colors)++] = color; + } + else + s++; + } + + return *s ? -EINVAL : 0; +} + +size_param("llc-way-size", llc_way_size); + +static int __init parse_dom0_colors(const char *s) +{ + return parse_color_config(s, dom0_colors, &dom0_num_colors); +} +custom_param("dom0-colors", parse_dom0_colors); + +/* Return the LLC way size by probing the hardware */ +static unsigned int __init get_llc_way_size(void) +{ + register_t ccsidr_el1; + register_t clidr_el1 = READ_SYSREG(CLIDR_EL1); + register_t csselr_el1 = READ_SYSREG(CSSELR_EL1); + register_t id_aa64mmfr2_el1 = READ_SYSREG(ID_AA64MMFR2_EL1); + uint32_t ccsidr_numsets_shift = CCSIDR_NUMSETS_SHIFT; + uint32_t ccsidr_numsets_mask = CCSIDR_NUMSETS_MASK; + unsigned int n, line_size, num_sets; + + for ( n = CLIDR_CTYPEn_LEVELS; + n != 0 && !((clidr_el1 >> CLIDR_CTYPEn_SHIFT(n)) & CLIDR_CTYPEn_MASK); + n-- ); + + if ( n == 0 ) + return 0; + + WRITE_SYSREG(((n - 1) & CCSELR_LEVEL_MASK) << CCSELR_LEVEL_SHIFT, + CSSELR_EL1); + isb(); + + ccsidr_el1 = READ_SYSREG(CCSIDR_EL1); + + /* Arm ARM: (Log2(Number of bytes in cache line)) - 4 */ + line_size = 1 << ((ccsidr_el1 & CCSIDR_LINESIZE_MASK) + 4); + + /* If FEAT_CCIDX is enabled, CCSIDR_EL1 has a different bit layout */ + if ( (id_aa64mmfr2_el1 >> ID_AA64MMFR2_CCIDX_SHIFT) & 0x7 ) + { + ccsidr_numsets_shift = CCSIDR_NUMSETS_SHIFT_FEAT_CCIDX; + ccsidr_numsets_mask = CCSIDR_NUMSETS_MASK_FEAT_CCIDX; + } + /* Arm ARM: (Number of sets in cache) - 1 */ + num_sets = ((ccsidr_el1 >> ccsidr_numsets_shift) & ccsidr_numsets_mask) + 1; + + printk(XENLOG_INFO "LLC found: L%u (line size: %u bytes, sets num: %u)\n", + n, line_size, num_sets); + + /* Restore value in CSSELR_EL1 */ + WRITE_SYSREG(csselr_el1, CSSELR_EL1); + isb(); + + return line_size * num_sets; +} + +static bool check_colors(unsigned int *colors, unsigned int num_colors) +{ + unsigned int i; + + if ( num_colors > max_colors ) + return false; + + for ( i = 0; i < num_colors; i++ ) + if ( colors[i] >= max_colors ) + return false; + + return true; +} + +static unsigned int set_default_domain_colors(unsigned int *colors) +{ + unsigned int i; + + if ( !colors ) + return 0; + + for ( i = 0; i < max_colors; i++ ) + colors[i] = i; + return max_colors; +} + +static void dump_coloring_info(unsigned char key) +{ + printk("'%c' pressed -> dumping coloring general info\n", key); + printk("LLC way size: %u KiB\n", llc_way_size >> 10); + printk("Number of LLC colors supported: %u\n", max_colors); + printk("Address color mask: 0x%lx\n", addr_col_mask); +} + +bool __init coloring_init(void) +{ + if ( !llc_way_size && !(llc_way_size = get_llc_way_size()) ) + { + printk(XENLOG_ERR + "Probed LLC way size is 0 and no custom value provided\n"); + return false; + } + + /* + * The maximum number of colors must be a power of 2 in order to correctly + * map colors to bits of an address, so also the LLC way size must be so. + */ + if ( llc_way_size & (llc_way_size - 1) ) + { + printk(XENLOG_WARNING "LLC way size (%u) isn't a power of 2.\n", + llc_way_size); + llc_way_size = 1U << flsl(llc_way_size); + printk(XENLOG_WARNING + "Using %u instead. Performances will be suboptimal\n", + llc_way_size); + } + + max_colors = llc_way_size >> PAGE_SHIFT; + + if ( max_colors < 2 || max_colors > CONFIG_MAX_CACHE_COLORS ) + { + printk(XENLOG_ERR + "Max number of colors (%u) not in range [2, config max (%u)]\n", + max_colors, CONFIG_MAX_CACHE_COLORS); + return false; + } + + addr_col_mask = (max_colors - 1) << PAGE_SHIFT; + + if ( !dom0_num_colors ) + { + printk(XENLOG_WARNING + "Dom0 color config not found. Using default (all colors)\n"); + dom0_num_colors = set_default_domain_colors(dom0_colors); + } + + if ( !check_colors(dom0_colors, dom0_num_colors) ) + { + printk(XENLOG_ERR "Bad color config for Dom0\n"); + return false; + } + + register_keyhandler('K', dump_coloring_info, "dump coloring info", 1); + + return true; +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/include/asm/coloring.h b/xen/arch/arm/include/asm/coloring.h new file mode 100644 index 0000000000..3b563d3b90 --- /dev/null +++ b/xen/arch/arm/include/asm/coloring.h @@ -0,0 +1,38 @@ +/* + * xen/arm/include/asm/coloring.h + * + * Coloring support for ARM + * + * Copyright (C) 2019 Xilinx Inc. + * + * Authors: + * Luca Miccio + * Carlo Nonato + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see . + */ +#ifndef __ASM_ARM_COLORING_H__ +#define __ASM_ARM_COLORING_H__ + +#ifdef CONFIG_CACHE_COLORING + +#include + +bool __init coloring_init(void); + +#else /* !CONFIG_CACHE_COLORING */ + +static inline bool __init coloring_init(void) { return true; } + +#endif /* CONFIG_CACHE_COLORING */ +#endif /* __ASM_ARM_COLORING_H__ */ diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h index 1dd81d7d52..85ff0caf1e 100644 --- a/xen/arch/arm/include/asm/processor.h +++ b/xen/arch/arm/include/asm/processor.h @@ -18,6 +18,22 @@ #define CTR_IDC_SHIFT 28 #define CTR_DIC_SHIFT 29 +/* CCSIDR Current Cache Size ID Register */ +#define CCSIDR_LINESIZE_MASK 0x7 +#define CCSIDR_NUMSETS_SHIFT 13 +#define CCSIDR_NUMSETS_MASK 0x3FFF +#define CCSIDR_NUMSETS_SHIFT_FEAT_CCIDX 32 +#define CCSIDR_NUMSETS_MASK_FEAT_CCIDX 0xFFFFFF + +/* CCSELR Cache Size Selection Register */ +#define CCSELR_LEVEL_MASK 0x7 +#define CCSELR_LEVEL_SHIFT 1 + +/* CLIDR Cache Level ID Register */ +#define CLIDR_CTYPEn_SHIFT(n) (3 * (n - 1)) +#define CLIDR_CTYPEn_MASK 0x7 +#define CLIDR_CTYPEn_LEVELS 7 + #define ICACHE_POLICY_VPIPT 0 #define ICACHE_POLICY_AIVIVT 1 #define ICACHE_POLICY_VIPT 2 diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 4395640019..acc3e4ad72 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -53,6 +53,7 @@ #include #include #include +#include struct bootinfo __initdata bootinfo; @@ -1035,6 +1036,12 @@ void __init start_xen(unsigned long boot_phys_offset, printk("Command line: %s\n", cmdline); cmdline_parse(cmdline); + if ( IS_ENABLED(CONFIG_CACHE_COLORING) ) + { + if ( !coloring_init() ) + panic("Xen cache coloring support: setup failed\n"); + } + setup_mm(); /* Parse the ACPI tables for possible boot-time configuration */ diff --git a/xen/common/Kconfig b/xen/common/Kconfig index f1ea3199c8..d7968127be 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -31,6 +31,9 @@ config ARCH_MAP_DOMAIN_PAGE config HAS_ALTERNATIVE bool +config HAS_CACHE_COLORING + bool + config HAS_COMPAT bool From patchwork Sat Oct 22 15:51:13 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlo Nonato X-Patchwork-Id: 13016006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B3D86FA373F for ; Sat, 22 Oct 2022 15:51:58 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.428407.678483 (Exim 4.92) (envelope-from ) id 1omGmj-0002JL-On; Sat, 22 Oct 2022 15:51:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 428407.678483; Sat, 22 Oct 2022 15:51:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1omGmj-0002JD-Kn; Sat, 22 Oct 2022 15:51:41 +0000 Received: by outflank-mailman (input) for mailman id 428407; Sat, 22 Oct 2022 15:51:40 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1omGmi-000237-89 for xen-devel@lists.xenproject.org; Sat, 22 Oct 2022 15:51:40 +0000 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [2a00:1450:4864:20::536]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6a68df66-5221-11ed-8fd0-01056ac49cbb; Sat, 22 Oct 2022 17:51:39 +0200 (CEST) Received: by mail-ed1-x536.google.com with SMTP id l22so16367212edj.5 for ; Sat, 22 Oct 2022 08:51:39 -0700 (PDT) Received: from carlo-ubuntu.home (62-11-205-162.dialup.tiscali.it. [62.11.205.162]) by smtp.gmail.com with ESMTPSA id z61-20020a509e43000000b00461816beef9sm894623ede.14.2022.10.22.08.51.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Oct 2022 08:51:38 -0700 (PDT) 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: 6a68df66-5221-11ed-8fd0-01056ac49cbb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=7YEp+6/JGCHy6EQ4ajZKOuOH14rgPIjfh8TnzifmQQA=; b=aKRNEZiMt7Y8LQT/O0c2wMlSjtTVslJIVI1ImdR18eAIy+Uj7tqQa34aNe83fGjTyn csZ1x51Um/ctWKOnVibYdBe+iPNrPr/W2Vqspcq0C5w40HFspJuJIu0TT85iqatb2zau FtMn2i50MyyFtCbn4mc0bNXogRomJfORGErHJQJAg3A/8zY5EfWxaA/sg2TlqK5Q+0j5 bKbpPcpFDwYxMMq2eVDJZOLfDYpdqGlbD8PSICLXUTxRKXMHuS2bn9IF7t/wvj0TVLa3 Qcn/vIkgJZTHILWRlYgMtQZZ6rkG4f1QO7wQlL4nCh46L1OGMB19k3bis8N87fGqyuNG rmoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7YEp+6/JGCHy6EQ4ajZKOuOH14rgPIjfh8TnzifmQQA=; b=UH3eNWhgUqQCgnW5tmVUPllKT6gkW6hf436nH3+hjy7gZlp6UDTkjgH3AV/VwnQ9kI QizF9Nz/Lh6WkZApP+zb+jfZ/hxBK1N+nCsdr52EvL6XSTvi+uUgAK8XC02K8gyIfuQ1 qQQxKtdrtpZfopKDl2nJLJBNYAXnaOYqkP2gmZu0ooJaUB+NjJMUGETszDoIJ4Z6w6aq PNchfr4EVB7lOnzpKMlz9538XMQME4jFOE/9Dzom4x70auwuYfwVQNbUk4wvBJ3am/mD zDkPHMgJ2UnjNznT9hTLvhvZ4ZVZXV3bzw0rM9KNMBAsCEwKrEWF4XI1zvM1UEWBKWqM e/hA== X-Gm-Message-State: ACrzQf069DQlJNFpSwEj87yNr81uHzOsyCTGfy8Sb7lpVkguAjPa7+Uu bsY96w7MN1XW1g7s7/tnd0hmzbdOycKwgQ== X-Google-Smtp-Source: AMsMyM5V1jeTHV4nPjXGbtPqbhd2eNZm97l6V2GYwTsKhRtC/q9iij/cI9UK2L8Wi96OH/ZtqnEjSg== X-Received: by 2002:a17:906:db0d:b0:77b:a7cd:8396 with SMTP id xj13-20020a170906db0d00b0077ba7cd8396mr21339403ejb.264.1666453898534; Sat, 22 Oct 2022 08:51:38 -0700 (PDT) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: marco.solieri@unimore.it, andrea.bastoni@minervasys.tech, lucmiccio@gmail.com, Carlo Nonato , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Marco Solieri Subject: [PATCH v3 2/9] xen/arm: add cache coloring initialization for domains Date: Sat, 22 Oct 2022 17:51:13 +0200 Message-Id: <20221022155120.7000-3-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221022155120.7000-1-carlo.nonato@minervasys.tech> References: <20221022155120.7000-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 This commit adds array pointers to domains as well as to the hypercall and configuration structure employed in domain creation. The latter is used both by the toolstack and by Xen itself to pass configuration data to the domain creation function, so the XEN_GUEST_HANDLE macro must be adopted to be able to access guest memory in the first case. This implies special care for the copy of the configuration data into the domain data, meaning that a discrimination variable for the two possible code paths (coming from Xen or from the toolstack) is needed. The initialization and free functions for colored domains are also added. The former is responsible for allocating and populating the color array of the domain and it also checks for configuration issues. One of those issues is enabling both coloring and directmap for the domain because they contradicts one another. Since that, Dom0 must not be created with the directmap flag. The latter instead frees allocated memory. Based on original work from: Luca Miccio Signed-off-by: Carlo Nonato Signed-off-by: Marco Solieri --- v3: - xfree() for colors array in case of errors in domain_coloring_init() --- docs/misc/arm/cache-coloring.rst | 14 ++++++- xen/arch/arm/coloring.c | 57 +++++++++++++++++++++++++++++ xen/arch/arm/domain.c | 7 ++++ xen/arch/arm/domain_build.c | 13 ++++++- xen/arch/arm/include/asm/coloring.h | 10 +++++ xen/arch/arm/include/asm/domain.h | 4 ++ xen/include/public/arch-arm.h | 8 ++++ 7 files changed, 110 insertions(+), 3 deletions(-) diff --git a/docs/misc/arm/cache-coloring.rst b/docs/misc/arm/cache-coloring.rst index b0f9a2e917..e8ee8fafde 100644 --- a/docs/misc/arm/cache-coloring.rst +++ b/docs/misc/arm/cache-coloring.rst @@ -16,7 +16,7 @@ In order to enable and use it, few steps are needed. (refer to menuconfig help for value meaning and when it should be changed). CONFIG_MAX_CACHE_COLORS= -- Assign colors to Dom0 using the `Color selection format`_ (see +- Assign colors to domains using the `Color selection format`_ (see `Coloring parameters`_ for more documentation pointers). Background @@ -114,6 +114,9 @@ LLC way size (as previously discussed) and Dom0 colors can be set using the appropriate command line parameters. See the relevant documentation in "docs/misc/xen-command-line.pandoc". +Note that if no color configuration is provided for domains, they fallback to +the default one, which corresponds simply to all available colors. + Known issues and limitations **************************** @@ -133,3 +136,12 @@ too) is set to 2^15 = 32768 colors because of some limitation on the domain configuration structure size used in domain creation. "uint16_t" is the biggest integer type that fit the constraint and 2^15 is the biggest power of 2 it can easily represent. This value is big enough for the generic case, though. + + +"xen,static-mem" isn't supported when coloring is enabled +######################################################### + +In the domain configuration, "xen,static-mem" allows memory to be statically +allocated to the domain. This isn't possibile when cache coloring is enabled, +because that memory can't be guaranteed to be of the same colors assigned to +that domain. diff --git a/xen/arch/arm/coloring.c b/xen/arch/arm/coloring.c index 36eea2d6c0..a7b59f5aba 100644 --- a/xen/arch/arm/coloring.c +++ b/xen/arch/arm/coloring.c @@ -23,6 +23,7 @@ */ #include #include +#include #include #include #include @@ -232,6 +233,62 @@ bool __init coloring_init(void) return true; } +int domain_coloring_init(struct domain *d, + const struct xen_arch_domainconfig *config) +{ + if ( is_domain_direct_mapped(d) ) + { + printk(XENLOG_ERR + "Can't enable coloring and directmap at the same time for %pd\n", + d); + return -EINVAL; + } + + if ( is_hardware_domain(d) ) + { + d->arch.colors = dom0_colors; + d->arch.num_colors = dom0_num_colors; + } + else if ( config->num_colors == 0 ) + { + printk(XENLOG_WARNING + "Color config not found for %pd. Using default\n", d); + d->arch.colors = xzalloc_array(unsigned int, max_colors); + d->arch.num_colors = set_default_domain_colors(d->arch.colors); + } + else + { + d->arch.colors = xzalloc_array(unsigned int, config->num_colors); + d->arch.num_colors = config->num_colors; + if ( config->from_guest ) + copy_from_guest(d->arch.colors, config->colors, config->num_colors); + else + memcpy(d->arch.colors, config->colors.p, + sizeof(unsigned int) * config->num_colors); + } + + if ( !d->arch.colors ) + { + printk(XENLOG_ERR "Colors allocation failed for %pd\n", d); + return -ENOMEM; + } + + if ( !check_colors(d->arch.colors, d->arch.num_colors) ) + { + printk(XENLOG_ERR "Bad color config for %pd\n", d); + domain_coloring_free(d); + return -EINVAL; + } + + return 0; +} + +void domain_coloring_free(struct domain *d) +{ + if ( !is_hardware_domain(d) ) + xfree(d->arch.colors); +} + /* * Local variables: * mode: C diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 2d6253181a..b4dd64dff4 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -23,6 +23,7 @@ #include #include +#include #include #include #include @@ -712,6 +713,10 @@ int arch_domain_create(struct domain *d, ioreq_domain_init(d); #endif + if ( IS_ENABLED(CONFIG_CACHE_COLORING) && + (rc = domain_coloring_init(d, &config->arch)) ) + goto fail; + /* p2m_init relies on some value initialized by the IOMMU subsystem */ if ( (rc = iommu_domain_init(d, config->iommu_opts)) != 0 ) goto fail; @@ -807,6 +812,8 @@ void arch_domain_destroy(struct domain *d) get_order_from_bytes(d->arch.efi_acpi_len)); #endif domain_io_free(d); + if ( IS_ENABLED(CONFIG_CACHE_COLORING) ) + domain_coloring_free(d); } void arch_domain_shutdown(struct domain *d) diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 40e3c2e119..97f2060007 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -35,6 +35,12 @@ #define STATIC_EVTCHN_NODE_SIZE_CELLS 2 +#ifdef CONFIG_CACHE_COLORING +#define XEN_DOM0_CREATE_FLAGS CDF_privileged +#else +#define XEN_DOM0_CREATE_FLAGS CDF_privileged | CDF_directmap +#endif + static unsigned int __initdata opt_dom0_max_vcpus; integer_param("dom0_max_vcpus", opt_dom0_max_vcpus); @@ -3963,7 +3969,10 @@ static int __init construct_dom0(struct domain *d) /* type must be set before allocate_memory */ d->arch.type = kinfo.type; #endif - allocate_memory_11(d, &kinfo); + if ( IS_ENABLED(CONFIG_CACHE_COLORING) ) + allocate_memory(d, &kinfo); + else + allocate_memory_11(d, &kinfo); find_gnttab_region(d, &kinfo); #ifdef CONFIG_STATIC_SHM @@ -4025,7 +4034,7 @@ void __init create_dom0(void) if ( iommu_enabled ) dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu; - dom0 = domain_create(0, &dom0_cfg, CDF_privileged | CDF_directmap); + dom0 = domain_create(0, &dom0_cfg, XEN_DOM0_CREATE_FLAGS); if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) ) panic("Error creating domain 0\n"); diff --git a/xen/arch/arm/include/asm/coloring.h b/xen/arch/arm/include/asm/coloring.h index 3b563d3b90..0d2dfada10 100644 --- a/xen/arch/arm/include/asm/coloring.h +++ b/xen/arch/arm/include/asm/coloring.h @@ -27,12 +27,22 @@ #ifdef CONFIG_CACHE_COLORING #include +#include + +#include bool __init coloring_init(void); +int domain_coloring_init(struct domain *d, + const struct xen_arch_domainconfig *config); +void domain_coloring_free(struct domain *d); + #else /* !CONFIG_CACHE_COLORING */ static inline bool __init coloring_init(void) { return true; } +static inline int domain_coloring_init( + struct domain *d, const struct xen_arch_domainconfig *config) { return 0; } +static inline void domain_coloring_free(struct domain *d) {} #endif /* CONFIG_CACHE_COLORING */ #endif /* __ASM_ARM_COLORING_H__ */ diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h index 26a8348eed..291f7c375d 100644 --- a/xen/arch/arm/include/asm/domain.h +++ b/xen/arch/arm/include/asm/domain.h @@ -58,6 +58,10 @@ struct arch_domain #ifdef CONFIG_ARM_64 enum domain_type type; #endif +#ifdef CONFIG_CACHE_COLORING + unsigned int *colors; + unsigned int num_colors; +#endif /* Virtual MMU */ struct p2m_domain p2m; diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index c8b6058d3a..adf843a7a1 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -314,6 +314,8 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); #define XEN_DOMCTL_CONFIG_TEE_NONE 0 #define XEN_DOMCTL_CONFIG_TEE_OPTEE 1 +__DEFINE_XEN_GUEST_HANDLE(color_t, unsigned int); + struct xen_arch_domainconfig { /* IN/OUT */ uint8_t gic_version; @@ -335,6 +337,12 @@ struct xen_arch_domainconfig { * */ uint32_t clock_frequency; + /* IN */ + uint8_t from_guest; + /* IN */ + uint16_t num_colors; + /* IN */ + XEN_GUEST_HANDLE(color_t) colors; }; #endif /* __XEN__ || __XEN_TOOLS__ */ From patchwork Sat Oct 22 15:51:14 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlo Nonato X-Patchwork-Id: 13016005 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2A6A0FA3740 for ; Sat, 22 Oct 2022 15:51:59 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.428409.678500 (Exim 4.92) (envelope-from ) id 1omGml-0002gg-IH; Sat, 22 Oct 2022 15:51:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 428409.678500; Sat, 22 Oct 2022 15:51:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1omGml-0002dq-Cl; Sat, 22 Oct 2022 15:51:43 +0000 Received: by outflank-mailman (input) for mailman id 428409; Sat, 22 Oct 2022 15:51:41 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1omGmj-000237-P9 for xen-devel@lists.xenproject.org; Sat, 22 Oct 2022 15:51:41 +0000 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [2a00:1450:4864:20::530]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6b7dbd17-5221-11ed-8fd0-01056ac49cbb; Sat, 22 Oct 2022 17:51:41 +0200 (CEST) Received: by mail-ed1-x530.google.com with SMTP id m15so16314590edb.13 for ; Sat, 22 Oct 2022 08:51:41 -0700 (PDT) Received: from carlo-ubuntu.home (62-11-205-162.dialup.tiscali.it. [62.11.205.162]) by smtp.gmail.com with ESMTPSA id z61-20020a509e43000000b00461816beef9sm894623ede.14.2022.10.22.08.51.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Oct 2022 08:51:39 -0700 (PDT) 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: 6b7dbd17-5221-11ed-8fd0-01056ac49cbb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=44pwASrsnAtpDyfghbc69EETaGukeSYMbtotZhaVziA=; b=67egSdyQL5j+k0rN/iWcaUcLI1czr9vtDoWgZlfZPgZ/pUhPe8QBKsSV9mAAbyz1dD DxTEvp9iYYSk0yajTw62FmJ5xf1qz3SwLM1s3nO9ChGgAz/86GBvGFjwTzsTZQ8ln2I/ R8nCjfauW+gTeK8K/OYu0J6Wxv7MKhmzgNENwro9MOUWiOSeXHwMvY8/pa7d7dlB+utn 1/VD+x0DQUbO3STeE3w7KVxFwNpgGQtTbwv+AKEVSRkfbl/AONqXFlLYfxSVGiBje+5g GQAZEsGVuRiG2KBNB9itfOKRTZibjbn3vYiz5xo7s4V/OlOijTo9+r3YNNNipcIkrIUL lnGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=44pwASrsnAtpDyfghbc69EETaGukeSYMbtotZhaVziA=; b=AZIeJzQFwiYfzOy4JasOyfoA2dgvIG/6RqjhOZl7GCmdf8oP7aYM/NjQaVUtm+KHBr F8lH8Vk+J5mkWrXJeH1XFGRMcVUNZa+hZUCM7mh2b6XfnyIC2IR8HCbfop0tRyLz3WH4 FOWkKJcdBix+wEv0XHdttCBFOJ82FmUHoSk4h397Tn/i1Vdej3ZmWYjzKrw54LpeHlzy GuxuPr6lI6yxoQz3D9mgEEV1C1CKjOzQzvdGwvaf2fjKs9w5ae6h8tg++1kMVXq5yus3 gRuYGmcVjpuAeNazDJ70PlGdLUC1wZBYUc8GSKzMf9QOZEJ0VrX46W8pV52Pg3Y8wFUl HLBA== X-Gm-Message-State: ACrzQf05dtd+eiJlAhyDaJEGHtJtdDDEqSI9v/Mv/imUVqLdpdfIhbJI ggH6i2wH9P2pa6YksWkWCiiAUwnAd+c6bA== X-Google-Smtp-Source: AMsMyM6fXvk7dOHt5Y489MTW7mh6g9xd/jtS5DU9BKHmegYyol5/wT6I/wSwGz3b79bgbfbPVrA7Hg== X-Received: by 2002:a17:907:75c6:b0:79c:d3f4:4a14 with SMTP id jl6-20020a17090775c600b0079cd3f44a14mr6524923ejc.61.1666453900285; Sat, 22 Oct 2022 08:51:40 -0700 (PDT) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: marco.solieri@unimore.it, andrea.bastoni@minervasys.tech, lucmiccio@gmail.com, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Marco Solieri , Carlo Nonato Subject: [PATCH v3 3/9] xen/arm: dump cache colors in domain info debug-key Date: Sat, 22 Oct 2022 17:51:14 +0200 Message-Id: <20221022155120.7000-4-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221022155120.7000-1-carlo.nonato@minervasys.tech> References: <20221022155120.7000-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 From: Luca Miccio This commit adds cache colors to the information dumped with the domain info debug-key. Signed-off-by: Luca Miccio Signed-off-by: Marco Solieri Signed-off-by: Carlo Nonato --- xen/arch/arm/coloring.c | 16 ++++++++++++++++ xen/arch/arm/domain.c | 2 ++ xen/arch/arm/include/asm/coloring.h | 2 ++ 3 files changed, 20 insertions(+) diff --git a/xen/arch/arm/coloring.c b/xen/arch/arm/coloring.c index a7b59f5aba..cf8aa8a2ca 100644 --- a/xen/arch/arm/coloring.c +++ b/xen/arch/arm/coloring.c @@ -172,6 +172,16 @@ static unsigned int set_default_domain_colors(unsigned int *colors) return max_colors; } +static void print_colors(unsigned int *colors, unsigned int num_colors) +{ + unsigned int i; + + printk("[ "); + for ( i = 0; i < num_colors; i++ ) + printk("%u ", colors[i]); + printk("]\n"); +} + static void dump_coloring_info(unsigned char key) { printk("'%c' pressed -> dumping coloring general info\n", key); @@ -289,6 +299,12 @@ void domain_coloring_free(struct domain *d) xfree(d->arch.colors); } +void domain_dump_coloring_info(struct domain *d) +{ + printk("Domain %pd has %u colors: ", d, d->arch.num_colors); + print_colors(d->arch.colors, d->arch.num_colors); +} + /* * Local variables: * mode: C diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index b4dd64dff4..b174a192d4 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -1083,6 +1083,8 @@ int domain_relinquish_resources(struct domain *d) void arch_dump_domain_info(struct domain *d) { p2m_dump_info(d); + if ( IS_ENABLED(CONFIG_CACHE_COLORING) ) + domain_dump_coloring_info(d); } diff --git a/xen/arch/arm/include/asm/coloring.h b/xen/arch/arm/include/asm/coloring.h index 0d2dfada10..a16736819e 100644 --- a/xen/arch/arm/include/asm/coloring.h +++ b/xen/arch/arm/include/asm/coloring.h @@ -36,6 +36,7 @@ bool __init coloring_init(void); int domain_coloring_init(struct domain *d, const struct xen_arch_domainconfig *config); void domain_coloring_free(struct domain *d); +void domain_dump_coloring_info(struct domain *d); #else /* !CONFIG_CACHE_COLORING */ @@ -43,6 +44,7 @@ static inline bool __init coloring_init(void) { return true; } static inline int domain_coloring_init( struct domain *d, const struct xen_arch_domainconfig *config) { return 0; } static inline void domain_coloring_free(struct domain *d) {} +static inline void domain_dump_coloring_info(struct domain *d) {} #endif /* CONFIG_CACHE_COLORING */ #endif /* __ASM_ARM_COLORING_H__ */ From patchwork Sat Oct 22 15:51:15 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlo Nonato X-Patchwork-Id: 13016003 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B0809ECDFA1 for ; Sat, 22 Oct 2022 15:51:58 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.428410.678516 (Exim 4.92) (envelope-from ) id 1omGmm-00034B-P0; Sat, 22 Oct 2022 15:51:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 428410.678516; Sat, 22 Oct 2022 15:51:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1omGmm-00033a-Kh; Sat, 22 Oct 2022 15:51:44 +0000 Received: by outflank-mailman (input) for mailman id 428410; Sat, 22 Oct 2022 15:51:43 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1omGml-000237-IT for xen-devel@lists.xenproject.org; Sat, 22 Oct 2022 15:51:43 +0000 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [2a00:1450:4864:20::52f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6c818037-5221-11ed-8fd0-01056ac49cbb; Sat, 22 Oct 2022 17:51:42 +0200 (CEST) Received: by mail-ed1-x52f.google.com with SMTP id t18so830969edt.2 for ; Sat, 22 Oct 2022 08:51:42 -0700 (PDT) Received: from carlo-ubuntu.home (62-11-205-162.dialup.tiscali.it. [62.11.205.162]) by smtp.gmail.com with ESMTPSA id z61-20020a509e43000000b00461816beef9sm894623ede.14.2022.10.22.08.51.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Oct 2022 08:51:41 -0700 (PDT) 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: 6c818037-5221-11ed-8fd0-01056ac49cbb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=GWHHd85SPstIESW/WFPVLjHPxgYExJgUfYdkPnInDU0=; b=Dzb9hYPPPu6usKi60Q6B7t7Axb6jVxsv8FSp9T/5HkFdMuiqq2YMOGyEHcJhsSYO9w 9NMYXqhvdAKCGb53Pb67VI/NstyHbMLmjLUAhiiJk1fFpAW7Eg6UGrwdA8gqVNneKxUt IamPwmwA077mYZ0E3G8/mEJCFpFoTuhvOd3EzACz9TT3pA8EdaW5ylXEcm1qA1GeSsVE FUQRyxhSquci2Z3a2fYzlD87OXgdTQYXHYXPqKQTRNoyYDICNbMCdtGQ+YsKCHaaMtEZ 4SDBHJbX17KM0ZhfQjo5e1SFHxrKScdtIauaPp3tPOEdISyRJhaE3XbE3r6DdkkF0enC wL3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GWHHd85SPstIESW/WFPVLjHPxgYExJgUfYdkPnInDU0=; b=B7SH2Far6AuBO1tEeLUEVcw/FOGDGZSGbUlX/XWXbh2U58Z0Jp0vEOlzasLUD3YUvU ACa+u0zvZAsNStLZlJVEuAZLjl+G7vWckGWBUHfz450MRsYV1fNV2HUiknMouHJl6+BH 5vxXjuD6CvhGouP/iPW5cE7wItW2BAw81S95sq1+0UfHZC9j2hF7EP+09MieK8knzgf8 HjougUgp30peqMD9gS0B/gzd5k8eNcqDcoHe5qGhGL1lrxn4fvZ7Tl7JS4yZgVctsmgN zfuWeEDoBfOF1gcxz3PsEWB7gGtWHIAA1qilUTHRqB8yF426mSYRcELIuz89/qieysG7 gtFA== X-Gm-Message-State: ACrzQf1rUqojlzSmCDdYWKMNm4nQtHi0qwjH1fbLnP7exPc8a7bSu4+e CXTWe982hDHNQzt0XGT+q5cqpSis6hKzzA== X-Google-Smtp-Source: AMsMyM48uO6b+yWqGGzt/FDnV9UW58EoI4CDbhHjPxBWpSaUb+u1xH8OKvvBLb0srWjWjtKkern7Yw== X-Received: by 2002:a05:6402:5ca:b0:43b:6e01:482c with SMTP id n10-20020a05640205ca00b0043b6e01482cmr23173185edx.189.1666453902137; Sat, 22 Oct 2022 08:51:42 -0700 (PDT) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: marco.solieri@unimore.it, andrea.bastoni@minervasys.tech, lucmiccio@gmail.com, Carlo Nonato , Wei Liu , Anthony PERARD , Juergen Gross , Marco Solieri Subject: [PATCH v3 4/9] tools/xl: add support for cache coloring configuration Date: Sat, 22 Oct 2022 17:51:15 +0200 Message-Id: <20221022155120.7000-5-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221022155120.7000-1-carlo.nonato@minervasys.tech> References: <20221022155120.7000-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 Add a new "colors" parameter that defines the color assignment for a domain. The user can specify one or more color ranges using the same syntax used everywhere else for color config described in the documentation. The parameter is defined as a list of strings that represent the color ranges. Also documentation is added. Based on original work from: Luca Miccio Signed-off-by: Carlo Nonato Signed-off-by: Marco Solieri --- docs/man/xl.cfg.5.pod.in | 10 ++++++ tools/libs/light/libxl_create.c | 12 ++++++++ tools/libs/light/libxl_types.idl | 1 + tools/xl/xl_parse.c | 52 ++++++++++++++++++++++++++++++-- 4 files changed, 73 insertions(+), 2 deletions(-) diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index b2901e04cf..5f53cec8bf 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -2880,6 +2880,16 @@ Currently, only the "sbsa_uart" model is supported for ARM. =back +=over 4 + +=item B + +Specify the LLC color configuration for the guest. B can be either +a single color value or a hypen-separated closed interval of colors +(such as "0-4"). + +=back + =head3 x86 =over 4 diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c index b9dd2deedf..94c511912c 100644 --- a/tools/libs/light/libxl_create.c +++ b/tools/libs/light/libxl_create.c @@ -615,6 +615,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config, struct xs_permissions rwperm[1]; struct xs_permissions noperm[1]; xs_transaction_t t = 0; + DECLARE_HYPERCALL_BUFFER(unsigned int, colors); /* convenience aliases */ libxl_domain_create_info *info = &d_config->c_info; @@ -676,6 +677,16 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config, goto out; } + if (d_config->b_info.num_colors) { + size_t bytes = sizeof(unsigned int) * d_config->b_info.num_colors; + colors = xc_hypercall_buffer_alloc(ctx->xch, colors, bytes); + memcpy(colors, d_config->b_info.colors, bytes); + set_xen_guest_handle(create.arch.colors, colors); + create.arch.num_colors = d_config->b_info.num_colors; + create.arch.from_guest = 1; + LOG(DEBUG, "Setup %u domain colors", d_config->b_info.num_colors); + } + for (;;) { uint32_t local_domid; bool recent; @@ -922,6 +933,7 @@ retry_transaction: rc = 0; out: if (t) xs_transaction_end(ctx->xsh, t, 1); + if (colors) xc_hypercall_buffer_free(ctx->xch, colors); return rc; } diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl index d634f304cd..642173af1a 100644 --- a/tools/libs/light/libxl_types.idl +++ b/tools/libs/light/libxl_types.idl @@ -557,6 +557,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ ("ioports", Array(libxl_ioport_range, "num_ioports")), ("irqs", Array(uint32, "num_irqs")), ("iomem", Array(libxl_iomem_range, "num_iomem")), + ("colors", Array(uint32, "num_colors")), ("claim_mode", libxl_defbool), ("event_channels", uint32), ("kernel", string), diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index 1b5381cef0..e6b2c7acff 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -1220,8 +1220,9 @@ void parse_config_data(const char *config_source, XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms, *usbctrls, *usbdevs, *p9devs, *vdispls, *pvcallsifs_devs; XLU_ConfigList *channels, *ioports, *irqs, *iomem, *viridian, *dtdevs, - *mca_caps; - int num_ioports, num_irqs, num_iomem, num_cpus, num_viridian, num_mca_caps; + *mca_caps, *colors; + int num_ioports, num_irqs, num_iomem, num_cpus, num_viridian, num_mca_caps, + num_colors; int pci_power_mgmt = 0; int pci_msitranslate = 0; int pci_permissive = 0; @@ -1370,6 +1371,53 @@ void parse_config_data(const char *config_source, if (!xlu_cfg_get_long (config, "maxmem", &l, 0)) b_info->max_memkb = l * 1024; + if (!xlu_cfg_get_list(config, "colors", &colors, &num_colors, 0)) { + int k, p, cur_index = 0; + + b_info->num_colors = 0; + /* Get number of colors based on ranges */ + for (i = 0; i < num_colors; i++) { + uint32_t start = 0, end = 0; + + buf = xlu_cfg_get_listitem(colors, i); + if (!buf) { + fprintf(stderr, + "xl: Unable to get element %d in colors range list\n", i); + exit(1); + } + + if (sscanf(buf, "%u-%u", &start, &end) != 2) { + if (sscanf(buf, "%u", &start) != 1) { + fprintf(stderr, "xl: Invalid color range: %s\n", buf); + exit(1); + } + end = start; + } + else if (start > end) { + fprintf(stderr, + "xl: Start color is greater than end color: %s\n", buf); + exit(1); + } + + /* Check for overlaps */ + for (k = start; k <= end; k++) { + for (p = 0; p < b_info->num_colors; p++) { + if (b_info->colors[p] == k) { + fprintf(stderr, "xl: Overlapped ranges not allowed\n"); + exit(1); + } + } + } + + b_info->num_colors += (end - start) + 1; + b_info->colors = (uint32_t *)realloc(b_info->colors, + sizeof(*b_info->colors) * b_info->num_colors); + + for (k = start; k <= end; k++) + b_info->colors[cur_index++] = k; + } + } + if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) { vcpus = l; if (libxl_cpu_bitmap_alloc(ctx, &b_info->avail_vcpus, l)) { From patchwork Sat Oct 22 15:51:16 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlo Nonato X-Patchwork-Id: 13016002 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 452B4C04A95 for ; Sat, 22 Oct 2022 15:51:58 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.428411.678527 (Exim 4.92) (envelope-from ) id 1omGmp-0003OT-31; Sat, 22 Oct 2022 15:51:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 428411.678527; Sat, 22 Oct 2022 15:51:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1omGmo-0003OK-VY; Sat, 22 Oct 2022 15:51:46 +0000 Received: by outflank-mailman (input) for mailman id 428411; Sat, 22 Oct 2022 15:51:45 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1omGmn-000237-Na for xen-devel@lists.xenproject.org; Sat, 22 Oct 2022 15:51:45 +0000 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [2a00:1450:4864:20::530]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6ddd540c-5221-11ed-8fd0-01056ac49cbb; Sat, 22 Oct 2022 17:51:44 +0200 (CEST) Received: by mail-ed1-x530.google.com with SMTP id m15so16315002edb.13 for ; Sat, 22 Oct 2022 08:51:44 -0700 (PDT) Received: from carlo-ubuntu.home (62-11-205-162.dialup.tiscali.it. [62.11.205.162]) by smtp.gmail.com with ESMTPSA id z61-20020a509e43000000b00461816beef9sm894623ede.14.2022.10.22.08.51.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Oct 2022 08:51:43 -0700 (PDT) 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: 6ddd540c-5221-11ed-8fd0-01056ac49cbb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=3IqxEd6ecjPYBOtLoN10L6xas1AQwaOpYMS5dlVn26c=; b=AnibrlyVna0JrSAb+Wcx608MliwsWks84GNTUO3gu30o7DKgQLNyjjYMPpMdcVWfk8 dvd+CjWrZ+hH3VD8aIIEh/Vuk+I8wRj9n93vfsUDYUWsObo9orS1EpxSX4ONEJgdkB6i 8r+96FmkVCI4Zia20IHhdH8OO/hTK0BmunIay8Kx5n1OL8J/Rp/q5kMwZKwZTvTtPZbk c6axh+eNWabSv+VkBWw+0k9B0J6j3uoy+RyBu116L4xzXBEJFLNyLDcT2zn9FDy1cn0f pWQqtdFrD+fLM90dNR15b1KUZCQDi9+sLS+V38hiXf8oN9dtPtsRYDpbWoN3t2L6Q3dG 2Tpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3IqxEd6ecjPYBOtLoN10L6xas1AQwaOpYMS5dlVn26c=; b=zzFTw+JWFKGnCEChIQk/PQn3BMegkvl4nPwP3KOYM1zRMGVWtVHmAjn75fPbq0Ed3g Qfs0QyeMEUvWur7W+ByWg+o13f7tLNF6KAJnCqPQ9+Rp+Kahx1NCuBSRDScFQm4/66P9 zrEOKMcGZvVByLL8vlIszfbUYr5BIEylmtg9XsPWO8qj2ggO4UZUk4a35wP8MSZAd0kd zezZGAl5WRr1yEALxjjZC1zQkrHB3uG95XEgqtwv5F8rK7wWXZGAD0aqkxc/N+84yJEe Tj8JBY8D5/zOmLy9c/QiUlHiA4YTugPo4J9fbOX2g5mtF+mxVyQegq222SOg3W8fQKUt JD7Q== X-Gm-Message-State: ACrzQf0RieeIULocoQlcajLJ2xu0M8rpqfHFRskEstUO06Oxp4GM3gnQ G6Qo8rC6AD+mJlZMPz4jLQoRjZHluEae1g== X-Google-Smtp-Source: AMsMyM5kZAsF9pqs0EPB0QqBNlKxkIbAGyFH/lxOkA1oUz5eDfTOahALIsuwSHfCwkMqxwaJ5ad07Q== X-Received: by 2002:a17:907:2c4f:b0:78d:eebe:f413 with SMTP id hf15-20020a1709072c4f00b0078deebef413mr20626768ejc.221.1666453904210; Sat, 22 Oct 2022 08:51:44 -0700 (PDT) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: marco.solieri@unimore.it, andrea.bastoni@minervasys.tech, lucmiccio@gmail.com, Carlo Nonato , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Marco Solieri Subject: [PATCH v3 5/9] xen/arm: add support for cache coloring configuration via device-tree Date: Sat, 22 Oct 2022 17:51:16 +0200 Message-Id: <20221022155120.7000-6-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221022155120.7000-1-carlo.nonato@minervasys.tech> References: <20221022155120.7000-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 This commit adds the "colors" Device Tree attribute that can be used for DomUs and Dom0less color configurations. The syntax is the same used for every color config. Based on original work from: Luca Miccio Signed-off-by: Carlo Nonato Signed-off-by: Marco Solieri --- docs/misc/arm/cache-coloring.rst | 45 +++++++++++++++++++++++++++ docs/misc/arm/device-tree/booting.txt | 4 +++ xen/arch/arm/coloring.c | 17 ++++++++++ xen/arch/arm/domain_build.c | 13 ++++++++ xen/arch/arm/include/asm/coloring.h | 5 +++ 5 files changed, 84 insertions(+) diff --git a/docs/misc/arm/cache-coloring.rst b/docs/misc/arm/cache-coloring.rst index e8ee8fafde..dd2e851a26 100644 --- a/docs/misc/arm/cache-coloring.rst +++ b/docs/misc/arm/cache-coloring.rst @@ -114,6 +114,51 @@ LLC way size (as previously discussed) and Dom0 colors can be set using the appropriate command line parameters. See the relevant documentation in "docs/misc/xen-command-line.pandoc". +DomUs colors can be set either in the xl configuration file (relative +documentation at "docs/man/xl.cfg.pod.5.in") or via Device Tree, also for +Dom0less configurations, as in the following example: + +.. raw:: html + + 
+        xen,xen-bootargs = "console=dtuart dtuart=serial0 dom0_mem=1G dom0_max_vcpus=1 sched=null llc-way-size=64K xen-colors=0-1 dom0-colors=2-6";
+        xen,dom0-bootargs "console=hvc0 earlycon=xen earlyprintk=xen root=/dev/ram0"
+
+        dom0 {
+            compatible = "xen,linux-zimage" "xen,multiboot-module";
+            reg = <0x0 0x1000000 0x0 15858176>;
+        };
+
+        dom0-ramdisk {
+            compatible = "xen,linux-initrd" "xen,multiboot-module";
+            reg = <0x0 0x2000000 0x0 20638062>;
+        };
+
+        domU0 {
+            #address-cells = <0x1>;
+            #size-cells = <0x1>;
+            compatible = "xen,domain";
+            memory = <0x0 0x40000>;
+            colors = "4-8,10,11,12";
+            cpus = <0x1>;
+            vpl011 = <0x1>;
+
+            module@2000000 {
+                compatible = "multiboot,kernel", "multiboot,module";
+                reg = <0x2000000 0xffffff>;
+                bootargs = "console=ttyAMA0";
+            };
+
+            module@30000000 {
+                compatible = "multiboot,ramdisk", "multiboot,module";
+                reg = <0x3000000 0xffffff>;
+            };
+        };
+
+ +Please refer to the relative documentation in +"docs/misc/arm/device-tree/booting.txt". + Note that if no color configuration is provided for domains, they fallback to the default one, which corresponds simply to all available colors. diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt index c47a05e0da..3aa493c66d 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -162,6 +162,10 @@ with the following properties: An integer specifying the number of vcpus to allocate to the guest. +- colors + A string specifying the color configuration for the guest. Refer to + "docs/misc/arm/cache_coloring.rst" for syntax. + - vpl011 An empty property to enable/disable a virtual pl011 for the guest to diff --git a/xen/arch/arm/coloring.c b/xen/arch/arm/coloring.c index cf8aa8a2ca..685a431c3d 100644 --- a/xen/arch/arm/coloring.c +++ b/xen/arch/arm/coloring.c @@ -273,8 +273,11 @@ int domain_coloring_init(struct domain *d, if ( config->from_guest ) copy_from_guest(d->arch.colors, config->colors, config->num_colors); else + { memcpy(d->arch.colors, config->colors.p, sizeof(unsigned int) * config->num_colors); + xfree(config->colors.p); + } } if ( !d->arch.colors ) @@ -305,6 +308,20 @@ void domain_dump_coloring_info(struct domain *d) print_colors(d->arch.colors, d->arch.num_colors); } +void prepare_color_domain_config(struct xen_arch_domainconfig *config, + const char *colors_str) +{ + unsigned int num_colors; + + config->colors.p = xzalloc_array(unsigned int, max_colors); + if ( !config->colors.p ) + panic("Unable to allocate cache colors\n"); + + if ( parse_color_config(colors_str, config->colors.p, &num_colors) ) + panic("Error parsing the color configuration\n"); + config->num_colors = (uint16_t)num_colors; +} + /* * Local variables: * mode: C diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 97f2060007..b95e655331 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -25,6 +25,7 @@ #include #include #include +#include #include #include #include @@ -3826,6 +3827,7 @@ void __init create_domUs(void) struct dt_device_node *node; const struct dt_device_node *cpupool_node, *chosen = dt_find_node_by_path("/chosen"); + const char *colors_str; BUG_ON(chosen == NULL); dt_for_each_child_node(chosen, node) @@ -3914,6 +3916,17 @@ void __init create_domUs(void) d_cfg.cpupool_id = pool_id; } + if ( !dt_property_read_string(node, "colors", &colors_str) ) + { + if ( !IS_ENABLED(CONFIG_CACHE_COLORING) ) + printk(XENLOG_WARNING + "Property 'colors' found, but coloring is disabled\n"); + else if ( dt_find_property(node, "xen,static-mem", NULL) ) + panic("static-mem isn't allowed when coloring is enabled\n"); + else + prepare_color_domain_config(&d_cfg.arch, colors_str); + } + /* * The variable max_init_domid is initialized with zero, so here it's * very important to use the pre-increment operator to call diff --git a/xen/arch/arm/include/asm/coloring.h b/xen/arch/arm/include/asm/coloring.h index a16736819e..549eb408a3 100644 --- a/xen/arch/arm/include/asm/coloring.h +++ b/xen/arch/arm/include/asm/coloring.h @@ -38,6 +38,9 @@ int domain_coloring_init(struct domain *d, void domain_coloring_free(struct domain *d); void domain_dump_coloring_info(struct domain *d); +void prepare_color_domain_config(struct xen_arch_domainconfig *config, + const char *colors_str); + #else /* !CONFIG_CACHE_COLORING */ static inline bool __init coloring_init(void) { return true; } @@ -45,6 +48,8 @@ static inline int domain_coloring_init( struct domain *d, const struct xen_arch_domainconfig *config) { return 0; } static inline void domain_coloring_free(struct domain *d) {} static inline void domain_dump_coloring_info(struct domain *d) {} +static inline void prepare_color_domain_config( + struct xen_arch_domainconfig *config, const char *colors_str) {} #endif /* CONFIG_CACHE_COLORING */ #endif /* __ASM_ARM_COLORING_H__ */ From patchwork Sat Oct 22 15:51:17 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlo Nonato X-Patchwork-Id: 13016010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CD84AC04A95 for ; Sat, 22 Oct 2022 15:52:00 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.428412.678538 (Exim 4.92) (envelope-from ) id 1omGms-0003lK-F7; Sat, 22 Oct 2022 15:51:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 428412.678538; Sat, 22 Oct 2022 15:51:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1omGms-0003l3-As; Sat, 22 Oct 2022 15:51:50 +0000 Received: by outflank-mailman (input) for mailman id 428412; Sat, 22 Oct 2022 15:51:49 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1omGmq-000237-VP for xen-devel@lists.xenproject.org; Sat, 22 Oct 2022 15:51:49 +0000 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [2a00:1450:4864:20::52f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6f4a21bc-5221-11ed-8fd0-01056ac49cbb; Sat, 22 Oct 2022 17:51:47 +0200 (CEST) Received: by mail-ed1-x52f.google.com with SMTP id w8so14079932edc.1 for ; Sat, 22 Oct 2022 08:51:47 -0700 (PDT) Received: from carlo-ubuntu.home (62-11-205-162.dialup.tiscali.it. [62.11.205.162]) by smtp.gmail.com with ESMTPSA id z61-20020a509e43000000b00461816beef9sm894623ede.14.2022.10.22.08.51.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Oct 2022 08:51:45 -0700 (PDT) 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: 6f4a21bc-5221-11ed-8fd0-01056ac49cbb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=pm5NZV8ivNJJW7gXCvwFeNKDFFL/u9QvZuT7iBhn0cY=; b=WPbIgg1doPwjYuKhOlGtc/aH2wgwy2ZV2CEVKTDP6YwXiF8Nydigs3jRl5R9ySgBKe pgaavScDWQsgig3qvibbeMllwXemi2mzEipFRaErVqutLw2vONANBb/g82zyj2sBG9gl +o3zHVIfpMmM0DWvDWMWCue4upt4aUeG0IjPPS5W6fSeFJZ2fJwYzf9Jf9kEjZahv66k nmC2uWfzfdmTHPAfyodYkbZWxDaqV8MCeoyd7CkhhDS+7VVe1p65BgUwKI2UpRSj6H7a asuXUKz6PXmwoM6Rmn58Kd0kJG4eEhay1IVpKl8jGknFeS19xU3pfHM++x0o0qZq5Lcy dxgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pm5NZV8ivNJJW7gXCvwFeNKDFFL/u9QvZuT7iBhn0cY=; b=wlGZvxTtZl/ieCbmouNMICjMSZmO66xvPESKPkebQrCDC8z5yK/KBmPKX06ioTAX77 FwoIKrDKBnE8B/QuV5K7b68bpeNPbuIMZc3QwIh4odJBq876thr24+M/0OJVCgmSIjzU L3bFU9fFAv9JI/9UHnmEACekVN96P9+vwsXVGR54cWfCGWa3b8V+X3yFqa0SSov1CKb1 uaRsp9qxA15wEpwSCiZFD2H+s1JtxySlQyDnHFbKU53IOaVsC/bweu5YumMXkDpPC/Yu dSAoeeUp3//Q93JQuiOjeJOVXJwzhtrg5mWnZew5tcreVfmz8YMPJdOsm1BK5mSXfGZZ ANXQ== X-Gm-Message-State: ACrzQf2zZ79qtNA/twGTQnEp279RGdT1NmoaXcbreIWsJIkKVX5URRyG n5NeMc/AQALzsdXNx42UtTsNQZNi9zgBaA== X-Google-Smtp-Source: AMsMyM4QsEmAhIsc/c6qFUJDWgdszNUuPr24Jg9tFKoIrRyZOdA/6zRVpZL/EhrKZDzjb+1We2vmOA== X-Received: by 2002:a17:907:d93:b0:78d:fe7a:f1fe with SMTP id go19-20020a1709070d9300b0078dfe7af1femr20970678ejc.721.1666453906124; Sat, 22 Oct 2022 08:51:46 -0700 (PDT) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: marco.solieri@unimore.it, andrea.bastoni@minervasys.tech, lucmiccio@gmail.com, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu , Marco Solieri , Carlo Nonato Subject: [PATCH v3 6/9] xen/common: add cache coloring allocator for domains Date: Sat, 22 Oct 2022 17:51:17 +0200 Message-Id: <20221022155120.7000-7-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221022155120.7000-1-carlo.nonato@minervasys.tech> References: <20221022155120.7000-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 From: Luca Miccio This commit adds a new memory page allocator that implements the cache coloring mechanism. The allocation algorithm follows the given domain color configuration and maximizes contiguity in the page selection of multiple subsequent requests. Pages are stored in a color-indexed array of lists, each one sorted by machine address, that is called the colored heap. A simple initialization function computes the color of any available page and inserts it in the corresponding list. When a domain requests a page, the allocator takes one from the subset of lists whose colors equals the domain configuration. It chooses the page with the highest machine address such that contiguous pages are sequentially allocated, if this is made possible by a color assignment which includes adjacent colors. The allocator can handle only requests with order equals to 0 since the single color granularity is represented in memory by one page. The buddy allocator must coexist with the colored one because the Xen heap isn't colored. For this reason a new Kconfig option and a command line parameter are added to let the user set the amount of memory reserved for the buddy allocator. Even when cache coloring is enabled, this memory isn't managed by the colored allocator. Colored heap information is dumped in the dump_heap() debug-key function. Signed-off-by: Luca Miccio Signed-off-by: Marco Solieri Signed-off-by: Carlo Nonato --- v3: - fixed PGC_colored bits values - merged debug-key for dump_color_heap() with the one for dump_heap() - number of pages for each color in an array to easily dump color heap info - heap_lock in colored allocator to ensure atomicity and clarify it with a comment - added page_list_add_{next|prev} to add pages in the middle of the list - p2m tables use pages of same colors as domain - CONFIG_BUDDY_ALLOCATOR_SIZE is now an int (MiB) - buddy allocator reserved size is now respected as configured in Kconfig - removed useless functions and refactored the code - fixed PGC_colored flag that was removed when a page was allocated - merged with #7 since it would have been too small --- docs/misc/arm/cache-coloring.rst | 39 ++++- docs/misc/xen-command-line.pandoc | 14 ++ xen/arch/arm/Kconfig | 12 ++ xen/arch/arm/coloring.c | 10 ++ xen/arch/arm/include/asm/coloring.h | 6 + xen/arch/arm/include/asm/mm.h | 3 + xen/arch/arm/p2m.c | 7 +- xen/common/page_alloc.c | 259 +++++++++++++++++++++++++--- xen/include/xen/mm.h | 43 +++++ 9 files changed, 371 insertions(+), 22 deletions(-) diff --git a/docs/misc/arm/cache-coloring.rst b/docs/misc/arm/cache-coloring.rst index dd2e851a26..0c89278aee 100644 --- a/docs/misc/arm/cache-coloring.rst +++ b/docs/misc/arm/cache-coloring.rst @@ -16,6 +16,9 @@ In order to enable and use it, few steps are needed. (refer to menuconfig help for value meaning and when it should be changed). CONFIG_MAX_CACHE_COLORS= +- If needed, change the amount of memory reserved for the buddy allocator either + from the Xen configuration file, via the CONFIG_BUDDY_ALLOCATOR_SIZE value, + or with the command line option. See `Colored allocator and buddy allocator`. - Assign colors to domains using the `Color selection format`_ (see `Coloring parameters`_ for more documentation pointers). @@ -162,6 +165,18 @@ Please refer to the relative documentation in Note that if no color configuration is provided for domains, they fallback to the default one, which corresponds simply to all available colors. +Colored allocator and buddy allocator +************************************* + +The colored allocator distributes pages based on color configurations of +domains so that each domains only gets pages of its own colors. +The colored allocator is meant as an alternative to the buddy allocator because +its allocation policy is by definition incompatible with the generic one. Since +the Xen heap is not colored yet, we need to support the coexistence of the two +allocators and some memory must be left for the buddy one. +The buddy allocator memory can be reserved from the Xen configuration file or +with the help of a command-line option. + Known issues and limitations **************************** @@ -182,7 +197,6 @@ configuration structure size used in domain creation. "uint16_t" is the biggest integer type that fit the constraint and 2^15 is the biggest power of 2 it can easily represent. This value is big enough for the generic case, though. - "xen,static-mem" isn't supported when coloring is enabled ######################################################### @@ -190,3 +204,26 @@ In the domain configuration, "xen,static-mem" allows memory to be statically allocated to the domain. This isn't possibile when cache coloring is enabled, because that memory can't be guaranteed to be of the same colors assigned to that domain. + +Colored allocator can only make use of order-0 pages +#################################################### + +The cache coloring technique relies on memory mappings and on the smallest +amount of memory that can be mapped to achieve the maximum number of colors +(cache partitions) possible. This amount is what is normally called a page and, +in Xen terminology, the order-0 page is the smallest one. The fairly simple +colored allocator currently implemented, makes use only of such pages. +It must be said that a more complex one could, in theory, adopt higher order +pages if the colors selection contained adjacent colors. Two subsequent colors, +for example, can be represented by an order-1 page, four colors correspond to +an order-2 page, etc. + +Fail to boot colored DomUs with large memory size +################################################# + +If the Linux kernel used for Dom0 does not contain the upstream commit +3941552aec1e04d63999988a057ae09a1c56ebeb and uses the hypercall buffer device, +colored DomUs with memory size larger then 127 MB cannot be created. This is +caused by the default limit of this buffer of 64 pages. The solution is to +manually apply the above patch, or to check if there is an updated version of +the kernel in use for Dom0 that contains this change. diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 3f04414134..25a59dd6a9 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -299,6 +299,20 @@ can be maintained with the pv-shim mechanism. cause Xen not to use Indirect Branch Tracking even when support is available in hardware. +### buddy-alloc-size (arm64) +> `= ` + +> Default: `64M` + +Amount of memory reserved for the buddy allocator when colored allocator is +active. This options is parsed only when cache coloring support is enabled. +The colored allocator is meant as an alternative to the buddy allocator, +because its allocation policy is by definition incompatible with the +generic one. Since the Xen heap systems is not colored yet, we need to +support the coexistence of the two allocators for now. This parameter, which is +optional and for expert only, it's used to set the amount of memory reserved to +the buddy allocator. + ### clocksource (x86) > `= pit | hpet | acpi | tsc` diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index c45a9c5917..4cfa75b2ef 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -153,6 +153,18 @@ config MAX_CACHE_COLORS Note that if, at any time, a color configuration with more colors than the maximum is employed, an error is produced. +config BUDDY_ALLOCATOR_SIZE + int "Buddy allocator reserved memory size (MiB)" + default "64" + depends on CACHE_COLORING + help + Amount of memory reserved for the buddy allocator to work alongside + the colored one. The colored allocator is meant as an alternative to the + buddy allocator because its allocation policy is by definition + incompatible with the generic one. Since the Xen heap is not colored yet, + we need to support the coexistence of the two allocators and some memory + must be left for the buddy one. + config TEE bool "Enable TEE mediators support (UNSUPPORTED)" if UNSUPPORTED default n diff --git a/xen/arch/arm/coloring.c b/xen/arch/arm/coloring.c index 685a431c3d..2cae215cd2 100644 --- a/xen/arch/arm/coloring.c +++ b/xen/arch/arm/coloring.c @@ -322,6 +322,16 @@ void prepare_color_domain_config(struct xen_arch_domainconfig *config, config->num_colors = (uint16_t)num_colors; } +unsigned int page_to_color(const struct page_info *pg) +{ + return addr_to_color(page_to_maddr(pg)); +} + +unsigned int get_max_colors(void) +{ + return max_colors; +} + /* * Local variables: * mode: C diff --git a/xen/arch/arm/include/asm/coloring.h b/xen/arch/arm/include/asm/coloring.h index 549eb408a3..0147f95968 100644 --- a/xen/arch/arm/include/asm/coloring.h +++ b/xen/arch/arm/include/asm/coloring.h @@ -31,6 +31,8 @@ #include +struct page_info; + bool __init coloring_init(void); int domain_coloring_init(struct domain *d, @@ -41,6 +43,10 @@ void domain_dump_coloring_info(struct domain *d); void prepare_color_domain_config(struct xen_arch_domainconfig *config, const char *colors_str); +unsigned int page_to_color(const struct page_info *pg); + +unsigned int get_max_colors(void); + #else /* !CONFIG_CACHE_COLORING */ static inline bool __init coloring_init(void) { return true; } diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h index 68adcac9fa..e848fa4adf 100644 --- a/xen/arch/arm/include/asm/mm.h +++ b/xen/arch/arm/include/asm/mm.h @@ -128,6 +128,9 @@ struct page_info #else #define PGC_static 0 #endif +/* Page is cache colored */ +#define _PGC_colored PG_shift(4) +#define PGC_colored PG_mask(1, 4) /* ... */ /* Page is broken? */ #define _PGC_broken PG_shift(7) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 8449f97fe7..9ac7dc6216 100644 --- a/xen/arch/arm/p2m.c +++ b/xen/arch/arm/p2m.c @@ -661,7 +661,12 @@ static int p2m_create_table(struct p2m_domain *p2m, lpae_t *entry) ASSERT(!p2m_is_valid(*entry)); - page = alloc_domheap_page(NULL, 0); + /* If cache coloring is enabled, p2m tables are allocated using the domain + * coloring configuration to prevent cache interference. */ + if ( IS_ENABLED(CONFIG_CACHE_COLORING) ) + page = alloc_domheap_page(p2m->domain, MEMF_no_refcount); + else + page = alloc_domheap_page(NULL, 0); if ( page == NULL ) return -ENOMEM; diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 62afb07bc6..fe214cd6ac 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -150,6 +150,9 @@ #define p2m_pod_offline_or_broken_hit(pg) 0 #define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg != NULL) #endif +#ifdef CONFIG_HAS_CACHE_COLORING +#include +#endif #ifndef PGC_static #define PGC_static 0 @@ -231,6 +234,14 @@ static bool __read_mostly scrub_debug; #define scrub_debug false #endif +/* Memory required for buddy allocator to work with colored one */ +#ifdef CONFIG_BUDDY_ALLOCATOR_SIZE +static unsigned long __initdata buddy_alloc_size = + CONFIG_BUDDY_ALLOCATOR_SIZE << 20; +#else + static unsigned long __initdata buddy_alloc_size = 0; +#endif + /* * Bit width of the DMA heap -- used to override NUMA-node-first. * allocation strategy, which can otherwise exhaust low memory. @@ -440,7 +451,180 @@ mfn_t __init alloc_boot_pages(unsigned long nr_pfns, unsigned long pfn_align) BUG(); } +static DEFINE_SPINLOCK(heap_lock); +/* Initialise fields which have other uses for free pages. */ +static void init_free_page_fields(struct page_info *pg) +{ + pg->u.inuse.type_info = PGT_TYPE_INFO_INITIALIZER; + page_set_owner(pg, NULL); +} + +#ifdef CONFIG_CACHE_COLORING +/************************* + * COLORED SIDE-ALLOCATOR + * + * Pages are stored by their color in separate lists. Each list defines a color + * and it is initialized during end_boot_allocator, where each page's color + * is calculated and the page itself is put in the correct list. + * After initialization there will be N lists where N is the number of + * available colors on the platform. + * The {free|alloc}_color_heap_page overwrite pg->count_info, but they do it in + * the same way as the buddy allocator corresponding functions do: + * protecting the access with a critical section using heap_lock. + */ +typedef struct page_list_head colored_pages_t; +static colored_pages_t *__ro_after_init _color_heap; +static unsigned long *__ro_after_init free_colored_pages; + +#define color_heap(color) (&_color_heap[color]) + +static void free_color_heap_page(struct page_info *pg) +{ + struct page_info *pos; + unsigned int color = page_to_color(pg); + colored_pages_t *head = color_heap(color); + + spin_lock(&heap_lock); + + pg->count_info = PGC_state_free | PGC_colored; + page_set_owner(pg, NULL); + free_colored_pages[color]++; + + page_list_for_each( pos, head ) + { + if ( page_to_maddr(pos) < page_to_maddr(pg) ) + break; + } + + page_list_add_next(pg, pos, head); + + spin_unlock(&heap_lock); +} + +static struct page_info *alloc_color_heap_page(unsigned int memflags, + const unsigned int *colors, + unsigned int num_colors) +{ + struct page_info *pg = NULL; + unsigned int i, color; + bool need_tlbflush = false; + uint32_t tlbflush_timestamp = 0; + + spin_lock(&heap_lock); + + for ( i = 0; i < num_colors; i++ ) + { + struct page_info *tmp; + + if ( page_list_empty(color_heap(colors[i])) ) + continue; + + tmp = page_list_first(color_heap(colors[i])); + if ( !pg || page_to_maddr(tmp) > page_to_maddr(pg) ) + pg = tmp; + } + + if ( !pg ) + { + spin_unlock(&heap_lock); + return NULL; + } + + pg->count_info = PGC_state_inuse | PGC_colored; + + if ( !(memflags & MEMF_no_tlbflush) ) + accumulate_tlbflush(&need_tlbflush, pg, &tlbflush_timestamp); + + init_free_page_fields(pg); + flush_page_to_ram(mfn_x(page_to_mfn(pg)), + !(memflags & MEMF_no_icache_flush)); + + color = page_to_color(pg); + free_colored_pages[color]--; + page_list_del(pg, color_heap(color)); + + spin_unlock(&heap_lock); + + if ( need_tlbflush ) + filtered_flush_tlb_mask(tlbflush_timestamp); + + return pg; +} + +static void __init init_color_heap_pages(struct page_info *pg, + unsigned long nr_pages) +{ + unsigned int i; + + if ( !_color_heap ) + { + unsigned int max_colors = get_max_colors(); + + _color_heap = xmalloc_array(colored_pages_t, max_colors); + BUG_ON(!_color_heap); + free_colored_pages = xzalloc_array(unsigned long, max_colors); + BUG_ON(!free_colored_pages); + + for ( i = 0; i < max_colors; i++ ) + INIT_PAGE_LIST_HEAD(color_heap(i)); + } + + printk(XENLOG_DEBUG + "Init color heap with %lu pages starting from: %#"PRIx64"\n", + nr_pages, page_to_maddr(pg)); + + for ( i = 0; i < nr_pages; i++ ) + free_color_heap_page(&pg[i]); +} + +static struct page_info *alloc_color_domheap_page(struct domain *d, + unsigned int memflags) +{ + struct page_info *pg; + + pg = alloc_color_heap_page(memflags, d->arch.colors, d->arch.num_colors); + if ( !pg ) + return NULL; + + if ( !(memflags & MEMF_no_owner) ) + { + if ( memflags & MEMF_no_refcount ) + pg->count_info |= PGC_extra; + if ( assign_page(pg, 0, d, memflags) ) + { + free_color_heap_page(pg); + return NULL; + } + } + + return pg; +} + +static void dump_color_heap(void) +{ + unsigned int color; + + printk("Dumping coloring heap info\n"); + for ( color = 0; color < get_max_colors(); color++ ) + printk("Color heap[%u]: %lu pages\n", color, free_colored_pages[color]); +} + +integer_param("buddy-alloc-size", buddy_alloc_size); + +#else /* !CONFIG_CACHE_COLORING */ + +static void __init init_color_heap_pages(struct page_info *pg, + unsigned long nr_pages) {} +static struct page_info *alloc_color_domheap_page(struct domain *d, + unsigned int memflags) +{ + return NULL; +} +static void free_color_heap_page(struct page_info *pg) {} +static void dump_color_heap(void) {} + +#endif /* CONFIG_CACHE_COLORING */ /************************* * BINARY BUDDY ALLOCATOR @@ -462,7 +646,6 @@ static unsigned long node_need_scrub[MAX_NUMNODES]; static unsigned long *avail[MAX_NUMNODES]; static long total_avail_pages; -static DEFINE_SPINLOCK(heap_lock); static long outstanding_claims; /* total outstanding claims by all domains */ unsigned long domain_adjust_tot_pages(struct domain *d, long pages) @@ -1027,10 +1210,7 @@ static struct page_info *alloc_heap_pages( accumulate_tlbflush(&need_tlbflush, &pg[i], &tlbflush_timestamp); - /* Initialise fields which have other uses for free pages. */ - pg[i].u.inuse.type_info = PGT_TYPE_INFO_INITIALIZER; - page_set_owner(&pg[i], NULL); - + init_free_page_fields(&pg[i]); } spin_unlock(&heap_lock); @@ -1926,24 +2106,49 @@ static unsigned long avail_heap_pages( void __init end_boot_allocator(void) { unsigned int i; + unsigned long buddy_pages; - /* Pages that are free now go to the domain sub-allocator. */ - for ( i = 0; i < nr_bootmem_regions; i++ ) + buddy_pages = PFN_DOWN(buddy_alloc_size); + + if ( !IS_ENABLED(CONFIG_CACHE_COLORING) ) { - struct bootmem_region *r = &bootmem_region_list[i]; - if ( (r->s < r->e) && - (phys_to_nid(pfn_to_paddr(r->s)) == cpu_to_node(0)) ) + /* Pages that are free now go to the domain sub-allocator. */ + for ( i = 0; i < nr_bootmem_regions; i++ ) { - init_heap_pages(mfn_to_page(_mfn(r->s)), r->e - r->s); - r->e = r->s; - break; + struct bootmem_region *r = &bootmem_region_list[i]; + if ( (r->s < r->e) && + (phys_to_nid(pfn_to_paddr(r->s)) == cpu_to_node(0)) ) + { + init_heap_pages(mfn_to_page(_mfn(r->s)), r->e - r->s); + r->e = r->s; + break; + } } } + for ( i = nr_bootmem_regions; i-- > 0; ) { - struct bootmem_region *r = &bootmem_region_list[i]; + struct bootmem_region *r; + + if ( IS_ENABLED(CONFIG_CACHE_COLORING) ) + r = &bootmem_region_list[nr_bootmem_regions - i - 1]; + else + r = &bootmem_region_list[i]; + + if ( buddy_pages && (r->s < r->e) ) + { + unsigned long pages = MIN(r->e - r->s, buddy_pages); + init_heap_pages(mfn_to_page(_mfn(r->s)), pages); + r->s += pages; + buddy_pages -= pages; + } if ( r->s < r->e ) - init_heap_pages(mfn_to_page(_mfn(r->s)), r->e - r->s); + { + if ( IS_ENABLED(CONFIG_CACHE_COLORING) ) + init_color_heap_pages(mfn_to_page(_mfn(r->s)), r->e - r->s); + else + init_heap_pages(mfn_to_page(_mfn(r->s)), r->e - r->s); + } } nr_bootmem_regions = 0; @@ -2344,7 +2549,8 @@ int assign_pages( for ( i = 0; i < nr; i++ ) { - ASSERT(!(pg[i].count_info & ~(PGC_extra | PGC_static))); + ASSERT(!(pg[i].count_info & ~(PGC_extra | PGC_static | + PGC_colored))); if ( pg[i].count_info & PGC_extra ) extra_pages++; } @@ -2429,6 +2635,15 @@ struct page_info *alloc_domheap_pages( ASSERT_ALLOC_CONTEXT(); + /* Only domains are supported for coloring */ + if ( IS_ENABLED(CONFIG_CACHE_COLORING) && d ) + { + /* Colored allocation must be done on 0 order */ + if ( order ) + return NULL; + return alloc_color_domheap_page(d, memflags); + } + bits = domain_clamp_alloc_bitsize(memflags & MEMF_no_owner ? NULL : d, bits ? : (BITS_PER_LONG+PAGE_SHIFT)); @@ -2546,7 +2761,10 @@ void free_domheap_pages(struct page_info *pg, unsigned int order) scrub = 1; } - free_heap_pages(pg, order, scrub); + if ( pg->count_info & PGC_colored ) + free_color_heap_page(pg); + else + free_heap_pages(pg, order, scrub); } if ( drop_dom_ref ) @@ -2653,6 +2871,9 @@ static void cf_check dump_heap(unsigned char key) continue; printk("Node %d has %lu unscrubbed pages\n", i, node_need_scrub[i]); } + + if ( IS_ENABLED(CONFIG_CACHE_COLORING) ) + dump_color_heap(); } static __init int cf_check register_heap_trigger(void) @@ -2785,9 +3006,7 @@ static bool prepare_staticmem_pages(struct page_info *pg, unsigned long nr_mfns, * to PGC_state_inuse. */ pg[i].count_info = PGC_static | PGC_state_inuse; - /* Initialise fields which have other uses for free pages. */ - pg[i].u.inuse.type_info = PGT_TYPE_INFO_INITIALIZER; - page_set_owner(&pg[i], NULL); + init_free_page_fields(&pg[i]); } spin_unlock(&heap_lock); diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index a925028ab3..0d48502e75 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -297,6 +297,37 @@ page_list_add_tail(struct page_info *page, struct page_list_head *head) } head->tail = page; } +static inline void +_page_list_add(struct page_info *new, struct page_info *prev, + struct page_info *next) +{ + new->list.prev = page_to_pdx(prev); + new->list.next = page_to_pdx(next); + prev->list.next = page_to_pdx(new); + next->list.prev = page_to_pdx(new); +} +static inline void +page_list_add_next(struct page_info *new, struct page_info *prev, + struct page_list_head *head) +{ + struct page_info *next = page_list_next(prev, head); + + if ( !next ) + page_list_add_tail(new, head); + else + _page_list_add(new, prev, next); +} +static inline void +page_list_add_prev(struct page_info *new, struct page_info *next, + struct page_list_head *head) +{ + struct page_info *prev = page_list_prev(next, head); + + if ( !prev ) + page_list_add(new, head); + else + _page_list_add(new, prev, next); +} static inline bool_t __page_list_del_head(struct page_info *page, struct page_list_head *head, struct page_info *next, struct page_info *prev) @@ -449,6 +480,18 @@ page_list_add_tail(struct page_info *page, struct page_list_head *head) list_add_tail(&page->list, head); } static inline void +page_list_add_next(struct page_info *new, struct page_info *prev, + struct page_list_head *head) +{ + page_list_add_tail(new, &prev->list); +} +static inline void +page_list_add_prev(struct page_info *new, struct page_info *next, + struct page_list_head *head) +{ + page_list_add(new, &next->list); +} +static inline void page_list_del(struct page_info *page, struct page_list_head *head) { list_del(&page->list); From patchwork Sat Oct 22 15:51:18 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlo Nonato X-Patchwork-Id: 13016007 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C2DAAFA3742 for ; Sat, 22 Oct 2022 15:51:59 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.428413.678549 (Exim 4.92) (envelope-from ) id 1omGmu-00044W-2N; Sat, 22 Oct 2022 15:51:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 428413.678549; Sat, 22 Oct 2022 15:51:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1omGmt-000446-Te; Sat, 22 Oct 2022 15:51:51 +0000 Received: by outflank-mailman (input) for mailman id 428413; Sat, 22 Oct 2022 15:51:50 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1omGmr-000237-Vd for xen-devel@lists.xenproject.org; Sat, 22 Oct 2022 15:51:50 +0000 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [2a00:1450:4864:20::531]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6fdc77bb-5221-11ed-8fd0-01056ac49cbb; Sat, 22 Oct 2022 17:51:48 +0200 (CEST) Received: by mail-ed1-x531.google.com with SMTP id r14so16373436edc.7 for ; Sat, 22 Oct 2022 08:51:48 -0700 (PDT) Received: from carlo-ubuntu.home (62-11-205-162.dialup.tiscali.it. [62.11.205.162]) by smtp.gmail.com with ESMTPSA id z61-20020a509e43000000b00461816beef9sm894623ede.14.2022.10.22.08.51.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Oct 2022 08:51:47 -0700 (PDT) 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: 6fdc77bb-5221-11ed-8fd0-01056ac49cbb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=9CIJ7divhUZIF+Qnvd1Yc7OiBLngKxwy0fDcbHW1K4I=; b=bekSxZNXaB5EPog/MFSBYw65rHFpFZbEwHZNfxoGEjS6gxoEIRWu19yT+PZNGELIJ4 xpF7je+WIHIPIGcV2LP3zO3L7O7e6l8Z7qyfCLNqq74i7X8B0U1+DLGGhzojcqdSisBL 2ZrlhXCoqovBjr0nnw8bSSnsxjlXnxZU+uNMC6EM8W9qvcWks8mrbX5C0PsjrPBZv9g3 GnG/OnRWmCeRIwtmQmts6kudaiPb7HEHa6L2CoUfALvPe9+JGGDqv2UyHMfWsdvSaBwp f22JwHITKgKLtVvD+fbvABX604gHpTA5KE6bObc+gJ58esYS0gxIP+2gohyHmT3QSfwG GDhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9CIJ7divhUZIF+Qnvd1Yc7OiBLngKxwy0fDcbHW1K4I=; b=KlCpTpGT6aOj8/h268cz3dadUW+t7ue+7xlLYVZR5+LFlUTZp7z0eWhpR0MEIbusU6 4JOPgflE7ttQCs207n3J821f3Nn9zUUXvBfpnijzqFyY1ilUmSEbrMyTqgRNmVvcC2y4 z7ZkklimPsVG4fXkZj5WUiu69Wi3OtXXTpHCmbsJ6vTX0mAjcvZDUNKYHxuYtat7qMcl qb+GBNn9tjXErzmE9nYYvY9HbE/pBUEtP38Vnl3h1f85EVzZ3vNZXEdM2SYPeRMXE9Nh r1fGzNrH1wIVafhkjUfFrK1UWhLqfm5iLpAi5n4QTZ7zaDxqPG3ioGytIJJJwz40k7xw bZCw== X-Gm-Message-State: ACrzQf1XgLwa+OeTzY6S6RoV085RyeGhvPl6SvRgEKfreYIoWDAYZP0c Icd0iyCgCuIASDlRdAO94IDfUBcInmxz8w== X-Google-Smtp-Source: AMsMyM50hk0OxRgELBNWkoU6ZbKGwa3xx//p0nYsglz1A0zAss4XsD2nGCLTYRlYITflNQS7oGe5DQ== X-Received: by 2002:a17:906:ef8c:b0:78d:46b7:6847 with SMTP id ze12-20020a170906ef8c00b0078d46b76847mr20078591ejb.241.1666453907785; Sat, 22 Oct 2022 08:51:47 -0700 (PDT) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: marco.solieri@unimore.it, andrea.bastoni@minervasys.tech, lucmiccio@gmail.com, Carlo Nonato , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Marco Solieri Subject: [PATCH v3 7/9] Revert "xen/arm: Remove unused BOOT_RELOC_VIRT_START" Date: Sat, 22 Oct 2022 17:51:18 +0200 Message-Id: <20221022155120.7000-8-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221022155120.7000-1-carlo.nonato@minervasys.tech> References: <20221022155120.7000-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 This reverts commit 0c18fb76323bfb13615b6f13c98767face2d8097. Cache coloring support for Xen needs to relocate Xen code and data in a new colored physical space. The BOOT_RELOC_VIRT_START will be used as the virtual base address for a temporary mapping to this new space. Signed-off-by: Carlo Nonato Signed-off-by: Marco Solieri --- v3: - new revert because the commit reverted was introduced after v2 --- xen/arch/arm/include/asm/config.h | 4 +++- xen/arch/arm/mm.c | 1 + 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/include/asm/config.h b/xen/arch/arm/include/asm/config.h index 0fefed1b8a..ca6f775668 100644 --- a/xen/arch/arm/include/asm/config.h +++ b/xen/arch/arm/include/asm/config.h @@ -77,7 +77,8 @@ * 2M - 4M Xen text, data, bss * 4M - 6M Fixmap: special-purpose 4K mapping slots * 6M - 10M Early boot mapping of FDT - * 10M - 12M Livepatch vmap (if compiled in) + * 10M - 12M Early relocation address (used when relocating Xen) + * and later for livepatch vmap (if compiled in) * * ARM32 layout: * 0 - 12M @@ -113,6 +114,7 @@ #define BOOT_FDT_VIRT_START _AT(vaddr_t,0x00600000) #define BOOT_FDT_VIRT_SIZE _AT(vaddr_t, MB(4)) +#define BOOT_RELOC_VIRT_START _AT(vaddr_t,0x00a00000) #ifdef CONFIG_LIVEPATCH #define LIVEPATCH_VMAP_START _AT(vaddr_t,0x00a00000) #define LIVEPATCH_VMAP_SIZE _AT(vaddr_t, MB(2)) diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index 6ccffeaea5..a81b8f9286 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -154,6 +154,7 @@ static void __init __maybe_unused build_assertions(void) /* 2MB aligned regions */ BUILD_BUG_ON(XEN_VIRT_START & ~SECOND_MASK); BUILD_BUG_ON(FIXMAP_ADDR(0) & ~SECOND_MASK); + BUILD_BUG_ON(BOOT_RELOC_VIRT_START & ~SECOND_MASK); /* 1GB aligned regions */ #ifdef CONFIG_ARM_32 BUILD_BUG_ON(XENHEAP_VIRT_START & ~FIRST_MASK); From patchwork Sat Oct 22 15:51:19 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlo Nonato X-Patchwork-Id: 13016009 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E2D6EFA3743 for ; Sat, 22 Oct 2022 15:52:01 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.428414.678560 (Exim 4.92) (envelope-from ) id 1omGmv-0004MJ-Do; Sat, 22 Oct 2022 15:51:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 428414.678560; Sat, 22 Oct 2022 15:51:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1omGmv-0004Kr-7L; Sat, 22 Oct 2022 15:51:53 +0000 Received: by outflank-mailman (input) for mailman id 428414; Sat, 22 Oct 2022 15:51:51 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1omGmt-0002Ir-5o for xen-devel@lists.xenproject.org; Sat, 22 Oct 2022 15:51:51 +0000 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [2a00:1450:4864:20::52b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 710265bf-5221-11ed-91b5-6bf2151ebd3b; Sat, 22 Oct 2022 17:51:50 +0200 (CEST) Received: by mail-ed1-x52b.google.com with SMTP id a67so16325495edf.12 for ; Sat, 22 Oct 2022 08:51:50 -0700 (PDT) Received: from carlo-ubuntu.home (62-11-205-162.dialup.tiscali.it. [62.11.205.162]) by smtp.gmail.com with ESMTPSA id z61-20020a509e43000000b00461816beef9sm894623ede.14.2022.10.22.08.51.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Oct 2022 08:51:49 -0700 (PDT) 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: 710265bf-5221-11ed-91b5-6bf2151ebd3b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=1+bXc+eUGwUw9pKJuzS9R2sHd4FPFFlOJJczFfA/Xfo=; b=SVMkJvKI59q+DF9RWoWnNA6MKfFZUQcGyxWuatT+x2LZl5gR2Kg+Qc7ue1fjFSf7nK qz/eSC0BnYzjP/3cdfdw9A5D7VmKK/ZkcZ7QJbBDgR4GhNgFVbFhmjCi7vMfZBvWUCNI vSs4ICN8sY8Xa0EDQ5xLsHpHnSpXJyyQD9UoXpPQYtrfLEmKdDNwpMyeqX2iMwc2yahK wc7qJOixltKVQjM710TXVHLFEGSvJRHZxelQxpLM6Tk6EublMbKQf1jTuO/TNy+4I5/p vinPxcmFIegiSpEI1eQEj5NkoiuwLwxe1VfEdwj5XcYDujxaNl0Z/7Cnc8cK4WloaTk6 +f2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=1+bXc+eUGwUw9pKJuzS9R2sHd4FPFFlOJJczFfA/Xfo=; b=vQPojUkQEVzFvPph2mRv1uMYGAliUyVCuvLqBAI38LYLgOR3ayh8391C57Y2KfRHNT Os9qPoLpcygiNFErQNrBwbYN8oHcuCn/kO6kUnXhYmGKYdQjKmXs5FwjAhvHAW/3Y+vD bCNkbg4jvO3wed1vcwZZcPUn6WP5L5U/zW8sVuVBvdE60JQ7rWAKKAuFkzGSF+xUpgnm MHJNPjy6Y8OBsOoaSu7uW5BWsngKEmi/IvyMnEnW43q8WhjoohYyEUDM4GRfJAJjr/wP giB0/biL2ZduCJR/xJ0JSf4CCzM+Jm0BT6NWi6oWxcTPupM9j4fPBD5cXOLWW5Who1KZ CErQ== X-Gm-Message-State: ACrzQf3YsuRyibeU3LR1g6qiLFQNuB2gW7b2JiyqaJqgo6272oP3r1QW bLDVy/4Qgwc4Rx0pzHmxLxNxQv52aTUKWQ== X-Google-Smtp-Source: AMsMyM5ezc5fcL/vFULr76ElxNM4qMC5gC1Qkvy2d09jfd8RqYnGhxgcRvLDj/ICdEDQ8rNj6bI16g== X-Received: by 2002:a17:906:ee89:b0:73d:70c5:1a4e with SMTP id wt9-20020a170906ee8900b0073d70c51a4emr19526601ejb.683.1666453909648; Sat, 22 Oct 2022 08:51:49 -0700 (PDT) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: marco.solieri@unimore.it, andrea.bastoni@minervasys.tech, lucmiccio@gmail.com, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu , Marco Solieri , Carlo Nonato Subject: [PATCH v3 8/9] xen/arm: add Xen cache colors command line parameter Date: Sat, 22 Oct 2022 17:51:19 +0200 Message-Id: <20221022155120.7000-9-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221022155120.7000-1-carlo.nonato@minervasys.tech> References: <20221022155120.7000-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 From: Luca Miccio This commit adds a new command line parameter to configure Xen cache colors. These colors can be dumped with the cache coloring info debug-key. By default, Xen uses the first color. Benchmarking the VM interrupt response time provides an estimation of LLC usage by Xen's most latency-critical runtime task. Results on Arm Cortex-A53 on Xilinx Zynq UltraScale+ XCZU9EG show that one color, which reserves 64 KiB of L2, is enough to attain best responsiveness. More colors are instead very likely to be needed on processors whose L1 cache is physically-indexed and physically-tagged, such as Cortex-A57. In such cases, coloring applies to L1 also, and there typically are two distinct L1-colors. Therefore, reserving only one color for Xen would senselessly partitions a cache memory that is already private, i.e. underutilize it. The default amount of Xen colors is thus set to one. Signed-off-by: Luca Miccio Signed-off-by: Marco Solieri Signed-off-by: Carlo Nonato --- docs/misc/arm/cache-coloring.rst | 8 ++++---- docs/misc/xen-command-line.pandoc | 9 +++++++++ xen/arch/arm/coloring.c | 30 ++++++++++++++++++++++++++++++ 3 files changed, 43 insertions(+), 4 deletions(-) diff --git a/docs/misc/arm/cache-coloring.rst b/docs/misc/arm/cache-coloring.rst index 0c89278aee..80eb259dfa 100644 --- a/docs/misc/arm/cache-coloring.rst +++ b/docs/misc/arm/cache-coloring.rst @@ -19,8 +19,8 @@ In order to enable and use it, few steps are needed. - If needed, change the amount of memory reserved for the buddy allocator either from the Xen configuration file, via the CONFIG_BUDDY_ALLOCATOR_SIZE value, or with the command line option. See `Colored allocator and buddy allocator`. -- Assign colors to domains using the `Color selection format`_ (see - `Coloring parameters`_ for more documentation pointers). +- Assign colors to each memory pool (Xen, Dom0/DomUs) using the + `Color selection format`_ for `Coloring parameters`_ configuration. Background ********** @@ -113,8 +113,8 @@ Examples: Coloring parameters ******************* -LLC way size (as previously discussed) and Dom0 colors can be set using the -appropriate command line parameters. See the relevant documentation in +LLC way size (as previously discussed), Xen colors and Dom0 colors can be set +using the appropriate command line parameters. See the relevant documentation in "docs/misc/xen-command-line.pandoc". DomUs colors can be set either in the xl configuration file (relative diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 25a59dd6a9..d831cf1196 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -2754,6 +2754,15 @@ In the case that x2apic is in use, this option switches between physical and clustered mode. The default, given no hint from the **FADT**, is cluster mode. +### xen-colors (arm64) +> `= List of [ | - ]` + +> Default: `0: the lowermost color` + +Specify Xen color configuration. +Two colors are most likely needed on platforms where private caches are +physically indexed, e.g. the L1 instruction cache of the Arm Cortex-A57. + ### xenheap_megabytes (arm32) > `= ` diff --git a/xen/arch/arm/coloring.c b/xen/arch/arm/coloring.c index 2cae215cd2..80c76c057f 100644 --- a/xen/arch/arm/coloring.c +++ b/xen/arch/arm/coloring.c @@ -32,6 +32,10 @@ #include #include +/* By default Xen uses the lowest color */ +#define XEN_DEFAULT_COLOR 0 +#define XEN_DEFAULT_NUM_COLORS 1 + /* Size of an LLC way */ static unsigned int __ro_after_init llc_way_size; /* Number of colors available in the LLC */ @@ -43,6 +47,9 @@ static uint64_t __ro_after_init addr_col_mask; #define addr_set_color(addr, color) (((addr) & ~addr_col_mask) \ | ((color) << PAGE_SHIFT)) +static unsigned int xen_colors[CONFIG_MAX_CACHE_COLORS]; +static unsigned int xen_num_colors; + static unsigned int dom0_colors[CONFIG_MAX_CACHE_COLORS]; static unsigned int dom0_num_colors; @@ -94,6 +101,12 @@ static int parse_color_config(const char *buf, unsigned int *colors, size_param("llc-way-size", llc_way_size); +static int __init parse_xen_colors(const char *s) +{ + return parse_color_config(s, xen_colors, &xen_num_colors); +} +custom_param("xen-colors", parse_xen_colors); + static int __init parse_dom0_colors(const char *s) { return parse_color_config(s, dom0_colors, &dom0_num_colors); @@ -188,6 +201,8 @@ static void dump_coloring_info(unsigned char key) printk("LLC way size: %u KiB\n", llc_way_size >> 10); printk("Number of LLC colors supported: %u\n", max_colors); printk("Address color mask: 0x%lx\n", addr_col_mask); + printk("Xen colors: "); + print_colors(xen_colors, xen_num_colors); } bool __init coloring_init(void) @@ -225,6 +240,21 @@ bool __init coloring_init(void) addr_col_mask = (max_colors - 1) << PAGE_SHIFT; + if ( !xen_num_colors ) + { + printk(XENLOG_WARNING + "Xen color config not found. Using default color: %u\n", + XEN_DEFAULT_COLOR); + xen_colors[0] = XEN_DEFAULT_COLOR; + xen_num_colors = XEN_DEFAULT_NUM_COLORS; + } + + if ( !check_colors(xen_colors, xen_num_colors) ) + { + printk(XENLOG_ERR "Bad color config for Xen\n"); + return false; + } + if ( !dom0_num_colors ) { printk(XENLOG_WARNING From patchwork Sat Oct 22 15:51:20 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlo Nonato X-Patchwork-Id: 13016011 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CFB04C04A95 for ; Sat, 22 Oct 2022 15:52:04 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.428415.678571 (Exim 4.92) (envelope-from ) id 1omGmw-0004fg-UH; Sat, 22 Oct 2022 15:51:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 428415.678571; Sat, 22 Oct 2022 15:51:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1omGmw-0004en-NP; Sat, 22 Oct 2022 15:51:54 +0000 Received: by outflank-mailman (input) for mailman id 428415; Sat, 22 Oct 2022 15:51:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1omGmv-0002Ir-HI for xen-devel@lists.xenproject.org; Sat, 22 Oct 2022 15:51:53 +0000 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [2a00:1450:4864:20::530]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 721860be-5221-11ed-91b5-6bf2151ebd3b; Sat, 22 Oct 2022 17:51:52 +0200 (CEST) Received: by mail-ed1-x530.google.com with SMTP id m16so16266780edc.4 for ; Sat, 22 Oct 2022 08:51:52 -0700 (PDT) Received: from carlo-ubuntu.home (62-11-205-162.dialup.tiscali.it. [62.11.205.162]) by smtp.gmail.com with ESMTPSA id z61-20020a509e43000000b00461816beef9sm894623ede.14.2022.10.22.08.51.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Oct 2022 08:51:50 -0700 (PDT) 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: 721860be-5221-11ed-91b5-6bf2151ebd3b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ZFHU6JLoOi1I0YfuDm34fjeeyfPVBZKSuGjuzgCHudY=; b=V4QBmMQvl4H72FfQBamm+SgPnsEFHKKbQ9hb1KjqZ75bMEG5AA2dkLikxDHouFocM0 lH0UxPXCCDyJBvhDN2UbCQsrxbjUHTM3WwcVgvTS/gQCtQ1inVVVckkYiGKEEZTNqyY9 RCdQwDV70Vx24HPQusiR0pPv5EVDUULAmX+VyVAE3anhkQ3nlPnC9A6t+B4+txHkesvg j+F72ItnBlZIcRE0nNdboGDLGhZXdMXT/aEgLZ2KFpFjofwZMjeDJ7/Zoj1jUEskvwmw 4X9qbSpXI1Brs+9fUM84NU6+VsdDhhnSXBpakC+dLvHRrX6SfxvqYSIPTZQWhlUaa4fW LPew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZFHU6JLoOi1I0YfuDm34fjeeyfPVBZKSuGjuzgCHudY=; b=mlCgoOSCypLp+uqV/8laP6xG1hLgTAhXfB3Oj/bTXYH+J8uezfkUVhpX17MfXsVDlM m+8xzPRGVPBByqnXhAGHwo1Zo+eRch0oBGhu/XCcktb69PQIzYF3SPq9uunfjeFsDtdF 2u/p6ty8XVfLLBkPdshuTDSwlpDxmwceqp0so110RgcA3usf93X+mmmpchpeqyBiBs2f uq4qyV7leiVFxgQAEsl4PSiEtIHpiILksWmIbRufB0Mt0Gj5pHI5Vo4lNO5hYuiM4I1E 2LR7nSOhx5WNVYEOj4Wv7qYRuAnmGaqqTBnbVIRc+3xlBpwRocKjP28ah+AjFWCRRkKZ zEow== X-Gm-Message-State: ACrzQf3dXZm5DdnPP+Bx7xEWjPrmIPtSuyrZanVC8kaEoE9s2QRrHLiX KyM0A0qysHRzbS9VdwEJIcWmV6wpurBEYQ== X-Google-Smtp-Source: AMsMyM7MXEiV5in+yFRYTeR2PvQuRsyLJ2/ximIm+nzAuVzWY1nblZJrbtht2OvIaG2j8sizGnZD4A== X-Received: by 2002:a17:906:5dce:b0:78d:e71a:6e0 with SMTP id p14-20020a1709065dce00b0078de71a06e0mr20198391ejv.360.1666453911187; Sat, 22 Oct 2022 08:51:51 -0700 (PDT) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: marco.solieri@unimore.it, andrea.bastoni@minervasys.tech, lucmiccio@gmail.com, Carlo Nonato , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Marco Solieri Subject: [PATCH v3 9/9] xen/arm: add cache coloring support for Xen Date: Sat, 22 Oct 2022 17:51:20 +0200 Message-Id: <20221022155120.7000-10-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221022155120.7000-1-carlo.nonato@minervasys.tech> References: <20221022155120.7000-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 This commit adds the cache coloring support for Xen own physical space. It extends the implementation of setup_pagetables to make use of Xen cache coloring configuration. Page tables construction is essentially the same except for the fact that the physical addresses, in case of cache coloring, are taken from the translation of a new, temporary, virtual space that is physically colored. The temporary mapping is also used to relocate Xen to the new physical space starting at the address taken from the old get_xen_paddr() function which is brought back for the occasion. The temporary mapping is finally converted to a mapping of the "old" (meaning the original physical space) Xen code, so that the boot CPU can actually address the variables and functions used by secondary CPUs. This happens when the boot CPU needs to bring up other CPUs (psci.c and smpboot.c) and when the TTBR value is passed to them (init_secondary_pagetables). Finally, since the alternative framework needs to remap the Xen text and inittext sections, this operation must be done in a coloring-aware way. The function xen_remap_colored() is introduced for that. Based on original work from: Luca Miccio Signed-off-by: Carlo Nonato Signed-off-by: Marco Solieri --- v3: - changed next_xen_colored() to xen_colored_mfn() to work with MFNs instead of addresses - new macro for_each_xen_colored_mfn to iterate over Xen colored MFNs - new function xen_remap_colored() to remap colored Xen instead of __vmap_colored() - use map_pages_to_xen() instead of custom mapping function during setup_pagetables() (thanks to Julien) - reintroduce relocate_xen() to switch to colored space - removed useless virt_to_maddr_colored() --- xen/arch/arm/alternative.c | 9 ++- xen/arch/arm/arm64/head.S | 48 +++++++++++++++ xen/arch/arm/coloring.c | 38 ++++++++++++ xen/arch/arm/include/asm/coloring.h | 30 +++++++++ xen/arch/arm/include/asm/mm.h | 16 ++++- xen/arch/arm/mm.c | 94 ++++++++++++++++++++++++++--- xen/arch/arm/psci.c | 4 +- xen/arch/arm/setup.c | 74 ++++++++++++++++++++++- xen/arch/arm/smpboot.c | 3 +- xen/arch/arm/xen.lds.S | 2 +- 10 files changed, 297 insertions(+), 21 deletions(-) diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c index f03cd943c6..a795aeec98 100644 --- a/xen/arch/arm/alternative.c +++ b/xen/arch/arm/alternative.c @@ -28,6 +28,7 @@ #include #include #include +#include #include #include #include @@ -220,8 +221,12 @@ void __init apply_alternatives_all(void) * The text and inittext section are read-only. So re-map Xen to * be able to patch the code. */ - xenmap = __vmap(&xen_mfn, 1U << xen_order, 1, 1, PAGE_HYPERVISOR, - VMAP_DEFAULT); + if ( IS_ENABLED(CONFIG_CACHE_COLORING) ) + xenmap = xen_remap_colored(xen_mfn, xen_size); + else + xenmap = __vmap(&xen_mfn, 1U << xen_order, 1, 1, PAGE_HYPERVISOR, + VMAP_DEFAULT); + /* Re-mapping Xen is not expected to fail during boot. */ BUG_ON(!xenmap); diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S index ad014716db..71cffb54fe 100644 --- a/xen/arch/arm/arm64/head.S +++ b/xen/arch/arm/arm64/head.S @@ -813,6 +813,54 @@ ENDPROC(fail) GLOBAL(_end_boot) +/* Copy Xen to new location and switch TTBR + * x0 ttbr + * x1 source address + * x2 destination address + * x3 length + * + * Source and destination must be word aligned, length is rounded up + * to a 16 byte boundary. + * + * MUST BE VERY CAREFUL when saving things to RAM over the copy */ +ENTRY(relocate_xen) + /* Copy 16 bytes at a time using: + * x9: counter + * x10: data + * x11: data + * x12: source + * x13: destination + */ + mov x9, x3 + mov x12, x1 + mov x13, x2 + +1: ldp x10, x11, [x12], #16 + stp x10, x11, [x13], #16 + + subs x9, x9, #16 + bgt 1b + + /* Flush destination from dcache using: + * x9: counter + * x10: step + * x11: vaddr + */ + dsb sy /* So the CPU issues all writes to the range */ + + mov x9, x3 + ldr x10, =dcache_line_bytes /* x10 := step */ + ldr x10, [x10] + mov x11, x2 + +1: dc cvac, x11 + + add x11, x11, x10 + subs x9, x9, x10 + bgt 1b + + b switch_ttbr + /* * Switch TTBR * diff --git a/xen/arch/arm/coloring.c b/xen/arch/arm/coloring.c index 80c76c057f..857a798d8a 100644 --- a/xen/arch/arm/coloring.c +++ b/xen/arch/arm/coloring.c @@ -27,6 +27,7 @@ #include #include #include +#include #include #include @@ -362,6 +363,43 @@ unsigned int get_max_colors(void) return max_colors; } +mfn_t xen_colored_mfn(mfn_t mfn) +{ + paddr_t maddr = mfn_to_maddr(mfn); + unsigned int i, color = addr_to_color(maddr); + + for( i = 0; i < xen_num_colors; i++ ) + { + if ( color == xen_colors[i] ) + return mfn; + else if ( color < xen_colors[i] ) + return maddr_to_mfn(addr_set_color(maddr, xen_colors[i])); + } + + /* Jump to next color space (llc_way_size bytes) and use the first color */ + return maddr_to_mfn(addr_set_color(maddr + llc_way_size, xen_colors[0])); +} + +void *xen_remap_colored(mfn_t xen_mfn, paddr_t xen_size) +{ + unsigned int i; + void *xenmap; + mfn_t *xen_colored_mfns = xmalloc_array(mfn_t, xen_size >> PAGE_SHIFT); + + if ( !xen_colored_mfns ) + panic("Can't allocate colored MFNs\n"); + + for_each_xen_colored_mfn( xen_mfn, i ) + { + xen_colored_mfns[i] = xen_mfn; + } + + xenmap = vmap(xen_colored_mfns, xen_size >> PAGE_SHIFT); + xfree(xen_colored_mfns); + + return xenmap; +} + /* * Local variables: * mode: C diff --git a/xen/arch/arm/include/asm/coloring.h b/xen/arch/arm/include/asm/coloring.h index 0147f95968..6e9c1212f5 100644 --- a/xen/arch/arm/include/asm/coloring.h +++ b/xen/arch/arm/include/asm/coloring.h @@ -27,10 +27,31 @@ #ifdef CONFIG_CACHE_COLORING #include +#include #include #include +/* + * Amount of memory that we need to map in order to color Xen. The value + * depends on the maximum number of available colors of the hardware. The + * memory size is pessimistically calculated assuming only one color is used, + * which means that any pages belonging to any other color has to be skipped. + */ +#define XEN_COLOR_MAP_SIZE \ + ROUNDUP((_end - _start) * get_max_colors(), XEN_PADDR_ALIGN) + +/** + * Iterate over each Xen mfn in the colored space. + * @mfn: the current mfn. The first non colored mfn must be provided as the + * starting point. + * @i: loop index. + */ +#define for_each_xen_colored_mfn(mfn, i) \ + for ( i = 0, mfn = xen_colored_mfn(mfn); \ + i < (_end - _start) >> PAGE_SHIFT; \ + i++, mfn = xen_colored_mfn(mfn_add(mfn, 1)) ) + struct page_info; bool __init coloring_init(void); @@ -47,8 +68,13 @@ unsigned int page_to_color(const struct page_info *pg); unsigned int get_max_colors(void); +mfn_t xen_colored_mfn(mfn_t mfn); +void *xen_remap_colored(mfn_t xen_fn, paddr_t xen_size); + #else /* !CONFIG_CACHE_COLORING */ +#define XEN_COLOR_MAP_SIZE (_end - _start) + static inline bool __init coloring_init(void) { return true; } static inline int domain_coloring_init( struct domain *d, const struct xen_arch_domainconfig *config) { return 0; } @@ -56,6 +82,10 @@ static inline void domain_coloring_free(struct domain *d) {} static inline void domain_dump_coloring_info(struct domain *d) {} static inline void prepare_color_domain_config( struct xen_arch_domainconfig *config, const char *colors_str) {} +static inline void *xen_remap_colored(mfn_t xen_fn, paddr_t xen_size) +{ + return NULL; +} #endif /* CONFIG_CACHE_COLORING */ #endif /* __ASM_ARM_COLORING_H__ */ diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h index e848fa4adf..f3f76a20b3 100644 --- a/xen/arch/arm/include/asm/mm.h +++ b/xen/arch/arm/include/asm/mm.h @@ -195,12 +195,26 @@ extern unsigned long total_pages; #define PDX_GROUP_SHIFT SECOND_SHIFT +#ifdef CONFIG_CACHE_COLORING +#define virt_to_boot_virt(virt) (virt - XEN_VIRT_START + BOOT_RELOC_VIRT_START) +#define set_value_for_secondary(var, val) \ + *(typeof(var) *)(virt_to_boot_virt((vaddr_t)&var)) = val; \ + clean_dcache(var); +#else +#define virt_to_boot_virt(virt) (virt) +#define set_value_for_secondary(var, val) \ + var = val; \ + clean_dcache(var); +#endif + /* Boot-time pagetable setup */ -extern void setup_pagetables(unsigned long boot_phys_offset); +extern void setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr); /* Map FDT in boot pagetable */ extern void *early_fdt_map(paddr_t fdt_paddr); /* Remove early mappings */ extern void remove_early_mappings(void); +/* Remove early coloring mappings */ +extern void remove_coloring_mappings(void); /* Allocate and initialise pagetables for a secondary CPU. Sets init_ttbr to the * new page table */ extern int init_secondary_pagetables(int cpu); diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index a81b8f9286..4721fd4a04 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -33,6 +33,7 @@ #include +#include #include #include @@ -105,6 +106,9 @@ DEFINE_BOOT_PAGE_TABLE(boot_third); static DEFINE_PAGE_TABLE(xen_pgtable); static DEFINE_PAGE_TABLE(xen_first); #define THIS_CPU_PGTABLE xen_pgtable +#ifdef CONFIG_CACHE_COLORING +static DEFINE_PAGE_TABLE(xen_colored_temp); +#endif #else #define HYP_PT_ROOT_LEVEL 1 /* Per-CPU pagetable pages */ @@ -364,7 +368,11 @@ void flush_page_to_ram(unsigned long mfn, bool sync_icache) static inline lpae_t pte_of_xenaddr(vaddr_t va) { +#ifdef CONFIG_CACHE_COLORING + paddr_t ma = virt_to_maddr(virt_to_boot_virt(va)); +#else paddr_t ma = va + phys_offset; +#endif return mfn_to_xen_entry(maddr_to_mfn(ma), MT_NORMAL); } @@ -450,6 +458,7 @@ static void xen_pt_enforce_wnx(void) flush_xen_tlb_local(); } +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len); extern void switch_ttbr(uint64_t ttbr); /* Clear a translation table and clean & invalidate the cache */ @@ -459,9 +468,54 @@ static void clear_table(void *table) clean_and_invalidate_dcache_va_range(table, PAGE_SIZE); } -/* Boot-time pagetable setup. - * Changes here may need matching changes in head.S */ -void __init setup_pagetables(unsigned long boot_phys_offset) +#ifdef CONFIG_CACHE_COLORING +static void __init create_coloring_temp_mappings(paddr_t xen_paddr) +{ + lpae_t pte; + unsigned int i; + mfn_t mfn = maddr_to_mfn(xen_paddr); + + for_each_xen_colored_mfn( mfn, i ) + { + pte = mfn_to_xen_entry(mfn, MT_NORMAL); + pte.pt.table = 1; /* level 3 mappings always have this bit set */ + xen_colored_temp[i] = pte; + } + + pte = mfn_to_xen_entry(virt_to_mfn(xen_colored_temp), MT_NORMAL); + pte.pt.table = 1; + write_pte(&boot_second[second_table_offset(BOOT_RELOC_VIRT_START)], pte); +} + +void __init remove_coloring_mappings(void) +{ + int rc; + + /* destroy the _PAGE_BLOCK mapping */ + rc = modify_xen_mappings(BOOT_RELOC_VIRT_START, + BOOT_RELOC_VIRT_START + SZ_2M, + _PAGE_BLOCK); + BUG_ON(rc); +} +#else +static void __init create_coloring_temp_mappings(paddr_t xen_paddr) {} +void __init remove_coloring_mappings(void) {} +#endif /* CONFIG_CACHE_COLORING */ + +/* + * Boot-time pagetable setup with coloring support + * Changes here may need matching changes in head.S + * + * The coloring support consists of: + * - Create a temporary colored mapping that conforms to Xen color selection. + * - pte_of_xenaddr takes care of translating the virtual addresses to the + * new colored physical space and the returns the pte, so that the page table + * initialization can remain the same. + * - Copy Xen to the new colored physical space by exploiting the temporary + * mapping. + * - Update TTBR0_EL2 with the new root page table address. + */ +void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr) { uint64_t ttbr; lpae_t pte, *p; @@ -469,6 +523,9 @@ void __init setup_pagetables(unsigned long boot_phys_offset) phys_offset = boot_phys_offset; + if ( IS_ENABLED(CONFIG_CACHE_COLORING) ) + create_coloring_temp_mappings(xen_paddr); + #ifdef CONFIG_ARM_64 p = (void *) xen_pgtable; p[0] = pte_of_xenaddr((uintptr_t)xen_first); @@ -515,13 +572,30 @@ void __init setup_pagetables(unsigned long boot_phys_offset) pte.pt.table = 1; xen_second[second_table_offset(FIXMAP_ADDR(0))] = pte; + if ( IS_ENABLED(CONFIG_CACHE_COLORING) ) + { + ttbr = virt_to_maddr(virt_to_boot_virt((vaddr_t)xen_pgtable)); + relocate_xen(ttbr, _start, (void *)BOOT_RELOC_VIRT_START, + _end - _start); + /* + * Keep original Xen memory mapped because secondary CPUs still point to it + * and a few variables needs to be accessed by the master CPU in order to + * let them boot. This mapping will also replace the one created at the + * beginning of setup_pagetables. + */ + map_pages_to_xen(BOOT_RELOC_VIRT_START, + maddr_to_mfn(XEN_VIRT_START + phys_offset), + SZ_2M >> PAGE_SHIFT, PAGE_HYPERVISOR_RW | _PAGE_BLOCK); + } + else + { #ifdef CONFIG_ARM_64 - ttbr = (uintptr_t) xen_pgtable + phys_offset; + ttbr = (uintptr_t) xen_pgtable + phys_offset; #else - ttbr = (uintptr_t) cpu0_pgtable + phys_offset; + ttbr = (uintptr_t) cpu0_pgtable + phys_offset; #endif - - switch_ttbr(ttbr); + switch_ttbr(ttbr); + } xen_pt_enforce_wnx(); @@ -552,8 +626,8 @@ int init_secondary_pagetables(int cpu) /* Set init_ttbr for this CPU coming up. All CPus share a single setof * pagetables, but rewrite it each time for consistency with 32 bit. */ - init_ttbr = (uintptr_t) xen_pgtable + phys_offset; - clean_dcache(init_ttbr); + set_value_for_secondary(init_ttbr, virt_to_maddr(xen_pgtable)); + return 0; } #else @@ -1109,7 +1183,7 @@ static int xen_pt_update(unsigned long virt, * * XXX: Add a check. */ - const mfn_t root = virt_to_mfn(THIS_CPU_PGTABLE); + const mfn_t root = maddr_to_mfn(READ_SYSREG64(TTBR0_EL2)); /* * The hardware was configured to forbid mapping both writeable and diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c index 0c90c2305c..4782f64c17 100644 --- a/xen/arch/arm/psci.c +++ b/xen/arch/arm/psci.c @@ -49,8 +49,8 @@ int call_psci_cpu_on(int cpu) { struct arm_smccc_res res; - arm_smccc_smc(psci_cpu_on_nr, cpu_logical_map(cpu), __pa(init_secondary), - &res); + arm_smccc_smc(psci_cpu_on_nr, cpu_logical_map(cpu), + __pa(virt_to_boot_virt((vaddr_t)init_secondary)), &res); return PSCI_RET(res); } diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index acc3e4ad72..6ad68b7f7e 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -465,7 +465,7 @@ static void * __init relocate_fdt(paddr_t dtb_paddr, size_t dtb_size) return fdt; } -#ifdef CONFIG_ARM_32 +#if defined (CONFIG_ARM_32) || (CONFIG_CACHE_COLORING) /* * Returns the end address of the highest region in the range s..e * with required size and alignment that does not conflict with the @@ -557,7 +557,9 @@ static paddr_t __init consider_modules(paddr_t s, paddr_t e, } return e; } +#endif +#ifdef CONFIG_ARM_32 /* * Find a contiguous region that fits in the static heap region with * required size and alignment, and return the end address of the region @@ -631,6 +633,62 @@ static paddr_t __init next_module(paddr_t s, paddr_t *end) return lowest; } +#ifdef CONFIG_CACHE_COLORING +/** + * get_xen_paddr - get physical address to relocate Xen to + * + * Xen is relocated to as near to the top of RAM as possible and + * aligned to a XEN_PADDR_ALIGN boundary. + */ +static paddr_t __init get_xen_paddr(uint32_t xen_size) +{ + struct meminfo *mi = &bootinfo.mem; + paddr_t min_size; + paddr_t paddr = 0; + int i; + + min_size = (xen_size + (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1); + + /* Find the highest bank with enough space. */ + for ( i = 0; i < mi->nr_banks; i++ ) + { + const struct membank *bank = &mi->bank[i]; + paddr_t s, e; + + if ( bank->size >= min_size ) + { + e = consider_modules(bank->start, bank->start + bank->size, + min_size, XEN_PADDR_ALIGN, 0); + if ( !e ) + continue; + +#ifdef CONFIG_ARM_32 + /* Xen must be under 4GB */ + if ( e > 0x100000000ULL ) + e = 0x100000000ULL; + if ( e < bank->start ) + continue; +#endif + + s = e - min_size; + + if ( s > paddr ) + paddr = s; + } + } + + if ( !paddr ) + panic("Not enough memory to relocate Xen\n"); + + printk("Placing Xen at 0x%"PRIpaddr"-0x%"PRIpaddr"\n", + paddr, paddr + min_size); + + return paddr; +} +#else +static paddr_t __init get_xen_paddr(uint32_t xen_size) { return 0; } +#endif + static void __init init_pdx(void) { paddr_t bank_start, bank_size, bank_end; @@ -1013,8 +1071,6 @@ void __init start_xen(unsigned long boot_phys_offset, /* Initialize traps early allow us to get backtrace when an error occurred */ init_traps(); - setup_pagetables(boot_phys_offset); - smp_clear_cpu_maps(); device_tree_flattened = early_fdt_map(fdt_paddr); @@ -1040,8 +1096,13 @@ void __init start_xen(unsigned long boot_phys_offset, { if ( !coloring_init() ) panic("Xen cache coloring support: setup failed\n"); + xen_bootmodule->size = XEN_COLOR_MAP_SIZE; + xen_bootmodule->start = get_xen_paddr(xen_bootmodule->size); } + setup_pagetables(boot_phys_offset, xen_bootmodule->start); + device_tree_flattened = early_fdt_map(fdt_paddr); + setup_mm(); /* Parse the ACPI tables for possible boot-time configuration */ @@ -1156,6 +1217,13 @@ void __init start_xen(unsigned long boot_phys_offset, setup_virt_paging(); + /* + * The removal is done earlier than discard_initial_modules beacuse the + * livepatch init uses a virtual address equal to BOOT_RELOC_VIRT_START. + * Remove coloring mappings to expose a clear state to the livepatch module. + */ + if ( IS_ENABLED(CONFIG_CACHE_COLORING) ) + remove_coloring_mappings(); do_initcalls(); /* diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c index f7bda3a18b..e7166ad79b 100644 --- a/xen/arch/arm/smpboot.c +++ b/xen/arch/arm/smpboot.c @@ -470,8 +470,7 @@ int __cpu_up(unsigned int cpu) init_data.cpuid = cpu; /* Open the gate for this CPU */ - smp_up_cpu = cpu_logical_map(cpu); - clean_dcache(smp_up_cpu); + set_value_for_secondary(smp_up_cpu, cpu_logical_map(cpu)); rc = arch_cpu_up(cpu); diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S index 92c2984052..333589c344 100644 --- a/xen/arch/arm/xen.lds.S +++ b/xen/arch/arm/xen.lds.S @@ -210,7 +210,7 @@ SECTIONS . = ALIGN(POINTER_ALIGN); __bss_end = .; } :text - _end = . ; + _end = ALIGN(PAGE_SIZE); /* Section for the device tree blob (if any). */ .dtb : { *(.dtb) } :text