All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v6 01/13] arm: remove the ARM HDLCD driver
  2018-06-13 21:14 [PATCH v6 0/13] arm: more kconfig configurability and small default configs Stefano Stabellini
@ 2018-06-13 21:14 ` Stefano Stabellini
  2018-06-13 21:14 ` [PATCH v6 02/13] arm: make it possible to disable HAS_GICV3 Stefano Stabellini
                   ` (11 subsequent siblings)
  12 siblings, 0 replies; 29+ messages in thread
From: Stefano Stabellini @ 2018-06-13 21:14 UTC (permalink / raw)
  To: julien.grall
  Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
	xen-devel

The ARM HDLCD driver is unused. The device itself can only be found on
Virtual Express boards that are for early development only. Remove the
driver.

Also remove vexpress_syscfg, now unused, and "select VIDEO" that is not
useful anymore.

Suggested-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Julien Grall <julien.grall@arm.com>
---
Changes in v3:
- remove "select VIDEO"
- remove vexpress_syscfg
Changes in v2:
- patch added
---
 xen/arch/arm/Kconfig                     |   2 -
 xen/arch/arm/platforms/vexpress.c        |  35 ----
 xen/drivers/video/Kconfig                |   3 -
 xen/drivers/video/Makefile               |   1 -
 xen/drivers/video/arm_hdlcd.c            | 281 -------------------------------
 xen/include/asm-arm/platforms/vexpress.h |   6 -
 6 files changed, 328 deletions(-)
 delete mode 100644 xen/drivers/video/arm_hdlcd.c

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 8174c0c..4dc7ef5 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -17,12 +17,10 @@ config ARM_64
 config ARM
 	def_bool y
 	select HAS_ALTERNATIVE
-	select HAS_ARM_HDLCD
 	select HAS_DEVICE_TREE
 	select HAS_MEM_ACCESS
 	select HAS_PASSTHROUGH
 	select HAS_PDX
-	select VIDEO
 
 config ARCH_DEFCONFIG
 	string
diff --git a/xen/arch/arm/platforms/vexpress.c b/xen/arch/arm/platforms/vexpress.c
index 70839d6..b6193f7 100644
--- a/xen/arch/arm/platforms/vexpress.c
+++ b/xen/arch/arm/platforms/vexpress.c
@@ -59,41 +59,6 @@ static inline int vexpress_ctrl_start(uint32_t *syscfg, int write,
     return 0;
 }
 
-int vexpress_syscfg(int write, int function, int device, uint32_t *data)
-{
-    uint32_t *syscfg = (uint32_t *) FIXMAP_ADDR(FIXMAP_MISC);
-    int ret = -1;
-
-    set_fixmap(FIXMAP_MISC, maddr_to_mfn(V2M_SYS_MMIO_BASE),
-               PAGE_HYPERVISOR_NOCACHE);
-
-    if ( syscfg[V2M_SYS_CFGCTRL/4] & V2M_SYS_CFG_START )
-        goto out;
-
-    /* clear the complete bit in the V2M_SYS_CFGSTAT status register */
-    syscfg[V2M_SYS_CFGSTAT/4] = 0;
-
-    if ( write )
-    {
-        /* write data */
-        syscfg[V2M_SYS_CFGDATA/4] = *data;
-
-        if ( vexpress_ctrl_start(syscfg, write, function, device) < 0 )
-            goto out;
-    } else {
-        if ( vexpress_ctrl_start(syscfg, write, function, device) < 0 )
-            goto out;
-        else
-            /* read data */
-            *data = syscfg[V2M_SYS_CFGDATA/4];
-    }
-
-    ret = 0;
-out:
-    clear_fixmap(FIXMAP_MISC);
-    return ret;
-}
-
 /*
  * TODO: Get base address from the device tree
  * See arm,vexpress-reset node
diff --git a/xen/drivers/video/Kconfig b/xen/drivers/video/Kconfig
index 52e8ce6..41ca503 100644
--- a/xen/drivers/video/Kconfig
+++ b/xen/drivers/video/Kconfig
@@ -11,6 +11,3 @@ config VGA
 	  Enable VGA output for the Xen hypervisor.
 
 	  If unsure, say Y.
-
-config HAS_ARM_HDLCD
-	bool
diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
index 2bb91d6..2b3fc76 100644
--- a/xen/drivers/video/Makefile
+++ b/xen/drivers/video/Makefile
@@ -4,4 +4,3 @@ obj-$(CONFIG_VIDEO) += font_8x16.o
 obj-$(CONFIG_VIDEO) += font_8x8.o
 obj-$(CONFIG_VIDEO) += lfb.o
 obj-$(CONFIG_VGA) += vesa.o
-obj-$(CONFIG_HAS_ARM_HDLCD) += arm_hdlcd.o
diff --git a/xen/drivers/video/arm_hdlcd.c b/xen/drivers/video/arm_hdlcd.c
deleted file mode 100644
index e1174b2..0000000
--- a/xen/drivers/video/arm_hdlcd.c
+++ /dev/null
@@ -1,281 +0,0 @@
-/*
- * xen/drivers/video/arm_hdlcd.c
- *
- * Driver for ARM HDLCD Controller
- *
- * Stefano Stabellini <stefano.stabellini@eu.citrix.com>
- * Copyright (c) 2013 Citrix Systems.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * 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.
- */
-
-#include <asm/delay.h>
-#include <asm/types.h>
-#include <asm/platforms/vexpress.h>
-#include <xen/device_tree.h>
-#include <xen/libfdt/libfdt.h>
-#include <xen/init.h>
-#include <xen/mm.h>
-#include "font.h"
-#include "lfb.h"
-#include "modelines.h"
-
-#define HDLCD ((volatile uint32_t *) FIXMAP_ADDR(FIXMAP_MISC))
-
-#define HDLCD_INTMASK       (0x18/4)
-#define HDLCD_FBBASE        (0x100/4)
-#define HDLCD_LINELENGTH    (0x104/4)
-#define HDLCD_LINECOUNT     (0x108/4)
-#define HDLCD_LINEPITCH     (0x10C/4)
-#define HDLCD_BUS           (0x110/4)
-#define HDLCD_VSYNC         (0x200/4)
-#define HDLCD_VBACK         (0x204/4)
-#define HDLCD_VDATA         (0x208/4)
-#define HDLCD_VFRONT        (0x20C/4)
-#define HDLCD_HSYNC         (0x210/4)
-#define HDLCD_HBACK         (0x214/4)
-#define HDLCD_HDATA         (0x218/4)
-#define HDLCD_HFRONT        (0x21C/4)
-#define HDLCD_POLARITIES    (0x220/4)
-#define HDLCD_COMMAND       (0x230/4)
-#define HDLCD_PF            (0x240/4)
-#define HDLCD_RED           (0x244/4)
-#define HDLCD_GREEN         (0x248/4)
-#define HDLCD_BLUE          (0x24C/4)
-
-struct color_masks {
-    int red_shift;
-    int red_size;
-    int green_shift;
-    int green_size;
-    int blue_shift;
-    int blue_size;
-};
-
-struct pixel_colors {
-    const char* bpp;
-    struct color_masks colors;
-};
-
-struct pixel_colors __initdata colors[] = {
-    { "16", { 0, 5, 11, 5, 6, 5 } },
-    { "24", { 0, 8, 16, 8, 8, 8 } },
-    { "32", { 0, 8, 16, 8, 8, 8 } },
-};
-
-static void vga_noop_puts(const char *s) {}
-void (*video_puts)(const char *) = vga_noop_puts;
-
-static void hdlcd_flush(void)
-{
-    dsb(sy);
-}
-
-static int __init get_color_masks(const char* bpp, struct color_masks **masks)
-{
-    int i;
-    for ( i = 0; i < ARRAY_SIZE(colors); i++ )
-    {
-        if ( !strncmp(colors[i].bpp, bpp, 2) )
-        {
-            *masks = &colors[i].colors;
-            return 0;
-        }
-    }
-    return -1;
-}
-
-static void __init set_pixclock(uint32_t pixclock)
-{
-    if ( dt_find_compatible_node(NULL, NULL, "arm,vexpress") )
-            vexpress_syscfg(1, V2M_SYS_CFG_OSC_FUNC,
-                            V2M_SYS_CFG_OSC5, &pixclock);
-}
-
-void __init video_init(void)
-{
-    struct lfb_prop lfbp;
-    unsigned char *lfb;
-    paddr_t hdlcd_start, hdlcd_size;
-    paddr_t framebuffer_start, framebuffer_size;
-    const char *mode_string;
-    char _mode_string[16];
-    int bytes_per_pixel = 4;
-    struct color_masks *c = NULL;
-    struct modeline *videomode = NULL;
-    int i;
-    const struct dt_device_node *dev;
-    const __be32 *cells;
-    u32 lenp;
-    int res;
-
-    dev = dt_find_compatible_node(NULL, NULL, "arm,hdlcd");
-
-    if ( !dev )
-    {
-        printk("HDLCD: Cannot find node compatible with \"arm,hdcld\"\n");
-        return;
-    }
-
-    res = dt_device_get_address(dev, 0, &hdlcd_start, &hdlcd_size);
-    if ( !res )
-    {
-        printk("HDLCD: Unable to retrieve MMIO base address\n");
-        return;
-    }
-
-    cells = dt_get_property(dev, "framebuffer", &lenp);
-    if ( !cells )
-    {
-        printk("HDLCD: Unable to retrieve framebuffer property\n");
-        return;
-    }
-
-    framebuffer_start = dt_next_cell(dt_n_addr_cells(dev), &cells);
-    framebuffer_size = dt_next_cell(dt_n_size_cells(dev), &cells);
-
-    if ( !hdlcd_start )
-    {
-        printk(KERN_ERR "HDLCD: address missing from device tree, disabling driver\n");
-        return;
-    }
-
-    if ( !framebuffer_start )
-    {
-        printk(KERN_ERR "HDLCD: framebuffer address missing from device tree, disabling driver\n");
-        return;
-    }
-
-    res = dt_property_read_string(dev, "mode", &mode_string);
-    if ( res )
-    {
-        get_color_masks("32", &c);
-        memcpy(_mode_string, "1280x1024@60", strlen("1280x1024@60") + 1);
-        bytes_per_pixel = 4;
-    }
-    else if ( strlen(mode_string) < strlen("800x600@60") ||
-            strlen(mode_string) > sizeof(_mode_string) - 1 )
-    {
-        printk(KERN_ERR "HDLCD: invalid modeline=%s\n", mode_string);
-        return;
-    } else {
-        char *s = strchr(mode_string, '-');
-        if ( !s )
-        {
-            printk(KERN_INFO "HDLCD: bpp not found in modeline %s, assume 32 bpp\n",
-                         mode_string);
-            get_color_masks("32", &c);
-            memcpy(_mode_string, mode_string, strlen(mode_string) + 1);
-            bytes_per_pixel = 4;
-        } else {
-            if ( strlen(s) < 6 )
-            {
-                printk(KERN_ERR "HDLCD: invalid mode %s\n", mode_string);
-                return;
-            }
-            s++;
-            if ( get_color_masks(s, &c) < 0 )
-            {
-                printk(KERN_WARNING "HDLCD: unsupported bpp %s\n", s);
-                return;
-            }
-            bytes_per_pixel = simple_strtoll(s, NULL, 10) / 8;
-        }
-        i = s - mode_string - 1;
-        memcpy(_mode_string, mode_string, i);
-        memcpy(_mode_string + i, mode_string + i + 3, 4);
-    }
-
-    for ( i = 0; i < ARRAY_SIZE(videomodes); i++ ) {
-        if ( !strcmp(_mode_string, videomodes[i].mode) )
-        {
-            videomode = &videomodes[i];
-            break;
-        }
-    }
-    if ( !videomode )
-    {
-        printk(KERN_WARNING "HDLCD: unsupported videomode %s\n",
-               _mode_string);
-        return;
-    }
-
-    if ( framebuffer_size < bytes_per_pixel * videomode->xres * videomode->yres )
-    {
-        printk(KERN_ERR "HDLCD: the framebuffer is too small, disabling the HDLCD driver\n");
-        return;
-    }
-
-    printk(KERN_INFO "Initializing HDLCD driver\n");
-
-    lfb = ioremap_wc(framebuffer_start, framebuffer_size);
-    if ( !lfb )
-    {
-        printk(KERN_ERR "Couldn't map the framebuffer\n");
-        return;
-    }
-    memset(lfb, 0x00, bytes_per_pixel * videomode->xres * videomode->yres);
-
-    /* uses FIXMAP_MISC */
-    set_pixclock(videomode->pixclock);
-
-    set_fixmap(FIXMAP_MISC, maddr_to_mfn(hdlcd_start), PAGE_HYPERVISOR_NOCACHE);
-    HDLCD[HDLCD_COMMAND] = 0;
-
-    HDLCD[HDLCD_LINELENGTH] = videomode->xres * bytes_per_pixel;
-    HDLCD[HDLCD_LINECOUNT] = videomode->yres - 1;
-    HDLCD[HDLCD_LINEPITCH] = videomode->xres * bytes_per_pixel;
-    HDLCD[HDLCD_PF] = ((bytes_per_pixel - 1) << 3);
-    HDLCD[HDLCD_INTMASK] = 0;
-    HDLCD[HDLCD_FBBASE] = framebuffer_start;
-    HDLCD[HDLCD_BUS] = 0xf00 | (1 << 4);
-    HDLCD[HDLCD_VBACK] = videomode->vback - 1;
-    HDLCD[HDLCD_VSYNC] = videomode->vsync - 1;
-    HDLCD[HDLCD_VDATA] = videomode->yres - 1;
-    HDLCD[HDLCD_VFRONT] = videomode->vfront - 1;
-    HDLCD[HDLCD_HBACK] = videomode->hback - 1;
-    HDLCD[HDLCD_HSYNC] = videomode->hsync - 1;
-    HDLCD[HDLCD_HDATA] = videomode->xres - 1;
-    HDLCD[HDLCD_HFRONT] = videomode->hfront - 1;
-    HDLCD[HDLCD_POLARITIES] = (1 << 2) | (1 << 3);
-    HDLCD[HDLCD_RED] = (c->red_size << 8) | c->red_shift;
-    HDLCD[HDLCD_GREEN] = (c->green_size << 8) | c->green_shift;
-    HDLCD[HDLCD_BLUE] = (c->blue_size << 8) | c->blue_shift;
-    HDLCD[HDLCD_COMMAND] = 1;
-    clear_fixmap(FIXMAP_MISC);
-
-    lfbp.pixel_on = (((1 << c->red_size) - 1) << c->red_shift) |
-        (((1 << c->green_size) - 1) << c->green_shift) |
-        (((1 << c->blue_size) - 1) << c->blue_shift);
-    lfbp.lfb = lfb;
-    lfbp.font = &font_vga_8x16;
-    lfbp.bits_per_pixel = bytes_per_pixel*8;
-    lfbp.bytes_per_line = bytes_per_pixel*videomode->xres;
-    lfbp.width = videomode->xres;
-    lfbp.height = videomode->yres;
-    lfbp.flush = hdlcd_flush;
-    lfbp.text_columns = videomode->xres / 8;
-    lfbp.text_rows = videomode->yres / 16;
-    if ( lfb_init(&lfbp) < 0 )
-            return;
-    video_puts = lfb_scroll_puts;
-}
-
-void __init video_endboot(void) { }
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/include/asm-arm/platforms/vexpress.h b/xen/include/asm-arm/platforms/vexpress.h
index 5cf3aba..8b45d3a 100644
--- a/xen/include/asm-arm/platforms/vexpress.h
+++ b/xen/include/asm-arm/platforms/vexpress.h
@@ -26,12 +26,6 @@
 /* Board-specific: base address of system controller */
 #define SP810_ADDRESS 0x1C020000
 
-#ifndef __ASSEMBLY__
-#include <xen/inttypes.h>
-
-int vexpress_syscfg(int write, int function, int device, uint32_t *data);
-#endif
-
 #endif /* __ASM_ARM_PLATFORMS_VEXPRESS_H */
 /*
  * Local variables:
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v6 02/13] arm: make it possible to disable HAS_GICV3
  2018-06-13 21:14 [PATCH v6 0/13] arm: more kconfig configurability and small default configs Stefano Stabellini
  2018-06-13 21:14 ` [PATCH v6 01/13] arm: remove the ARM HDLCD driver Stefano Stabellini
@ 2018-06-13 21:14 ` Stefano Stabellini
  2018-06-13 21:14 ` [PATCH v6 03/13] arm: rename HAS_GICV3 to GICV3 Stefano Stabellini
                   ` (10 subsequent siblings)
  12 siblings, 0 replies; 29+ messages in thread
From: Stefano Stabellini @ 2018-06-13 21:14 UTC (permalink / raw)
  To: julien.grall
  Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov,
	George.Dunlap, andrew.cooper3, Ian.Jackson, dfaggioli, jbeulich,
	xen-devel

Today it is a silent option. This patch adds a one line description and
makes it optional.

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Julien Grall <julien.grall@arm.com>
CC: George.Dunlap@eu.citrix.com
CC: Ian.Jackson@eu.citrix.com
CC: jbeulich@suse.com
CC: andrew.cooper3@citrix.com

---
Changes in v3:
- remove any changes to MEM_ACCESS
- update commit message

Changes in v2:
- make HAS_GICv3 depend on ARM_64
- remove modifications to ARM_HDLCD kconfig, it has been removed
---
 xen/arch/arm/Kconfig | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 4dc7ef5..fb69a66 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -12,7 +12,6 @@ config ARM_32
 config ARM_64
 	def_bool y
 	depends on 64BIT
-	select HAS_GICV3
 
 config ARM
 	def_bool y
@@ -42,6 +41,13 @@ config ACPI
 
 config HAS_GICV3
 	bool
+	prompt "GICv3 driver"
+	depends on ARM_64
+	default y
+	---help---
+
+	  Driver for the ARM Generic Interrupt Controller v3.
+	  If unsure, say Y
 
 config HAS_ITS
         bool
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v6 0/13] arm: more kconfig configurability and small default configs
@ 2018-06-13 21:14 Stefano Stabellini
  2018-06-13 21:14 ` [PATCH v6 01/13] arm: remove the ARM HDLCD driver Stefano Stabellini
                   ` (12 more replies)
  0 siblings, 13 replies; 29+ messages in thread
From: Stefano Stabellini @ 2018-06-13 21:14 UTC (permalink / raw)
  To: julien.grall
  Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov,
	andrew.cooper3, George.Dunlap, dfaggioli, xen-devel

Hi all,

This patch series is the first step toward building a small certifiable
Xen hypervisor for ARM boards.

The series makes a few changes to allow disabling more kconfig options:
most of them already exist but cannot be disabled. It also introduces a
reference kconfig for Renesas RCar (due to popular demand, candidate for
certifications), Xilinx MPSoC, and for QEMU aarch64 (not for
certifications, but useful for debugging).

The last three patches clarify and make changes to the security support
status of kconfig options in Xen. We might want to merge them into
previous patches, or move them earlier in the series. I am happy to do
that once we settled on the required wording for SUPPORT.md.

Cheers,

Stefano


Stefano Stabellini (13):
      arm: remove the ARM HDLCD driver
      arm: make it possible to disable HAS_GICV3
      arm: rename HAS_GICV3 to GICV3
      Make MEM_ACCESS configurable
      make it possible to enable/disable UART drivers
      arm: make it possible to disable the SMMU driver
      arm: add a tiny kconfig configuration
      arm: add ALL, QEMU, Rcar3 and MPSoC configs
      xen: add per-platform defaults for NR_CPUS
      xen: add cloc target
      xen: support the Null scheduler
      xen: specify support for EXPERT and DEBUG Kconfig options
      xen: clarify the security-support status of Kconfig options on ARM

 SUPPORT.md                               |  19 ++-
 tools/firmware/xen-dir/shim.config       |   2 +-
 xen/Makefile                             |  12 ++
 xen/arch/Kconfig                         |   3 +
 xen/arch/arm/Kconfig                     |  17 +-
 xen/arch/arm/Makefile                    |   4 +-
 xen/arch/arm/configs/tiny64.conf         |  43 +++++
 xen/arch/arm/platforms/Kconfig           |  55 ++++++
 xen/arch/arm/platforms/Makefile          |   2 +-
 xen/arch/arm/platforms/vexpress.c        |  35 ----
 xen/arch/arm/vgic.c                      |   2 +-
 xen/arch/arm/vgic/vgic.c                 |   2 +-
 xen/arch/x86/Kconfig                     |   2 +-
 xen/common/Kconfig                       |  12 +-
 xen/common/Makefile                      |   2 +-
 xen/common/domctl.c                      |   2 +-
 xen/drivers/char/Kconfig                 |  15 +-
 xen/drivers/passthrough/Kconfig          |  12 ++
 xen/drivers/passthrough/arm/Makefile     |   2 +-
 xen/drivers/video/Kconfig                |   3 -
 xen/drivers/video/Makefile               |   1 -
 xen/drivers/video/arm_hdlcd.c            | 281 -------------------------------
 xen/include/asm-arm/gic.h                |   4 +-
 xen/include/asm-arm/platforms/vexpress.h |   6 -
 xen/include/asm-arm/vgic.h               |   4 +-
 xen/include/xen/mem_access.h             |   4 +-
 xen/include/xsm/dummy.h                  |   2 +-
 xen/include/xsm/xsm.h                    |   4 +-
 xen/xsm/dummy.c                          |   2 +-
 xen/xsm/flask/hooks.c                    |   4 +-
 30 files changed, 194 insertions(+), 364 deletions(-)
 create mode 100644 xen/arch/arm/configs/tiny64.conf
 create mode 100644 xen/arch/arm/platforms/Kconfig
 delete mode 100644 xen/drivers/video/arm_hdlcd.c

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 29+ messages in thread

* [PATCH v6 03/13] arm: rename HAS_GICV3 to GICV3
  2018-06-13 21:14 [PATCH v6 0/13] arm: more kconfig configurability and small default configs Stefano Stabellini
  2018-06-13 21:14 ` [PATCH v6 01/13] arm: remove the ARM HDLCD driver Stefano Stabellini
  2018-06-13 21:14 ` [PATCH v6 02/13] arm: make it possible to disable HAS_GICV3 Stefano Stabellini
@ 2018-06-13 21:14 ` Stefano Stabellini
  2018-06-13 21:14 ` [PATCH v6 04/13] Make MEM_ACCESS configurable Stefano Stabellini
                   ` (9 subsequent siblings)
  12 siblings, 0 replies; 29+ messages in thread
From: Stefano Stabellini @ 2018-06-13 21:14 UTC (permalink / raw)
  To: julien.grall
  Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
	xen-devel

HAS_GICV3 has become selectable by the user. To mark the change, rename
the option from HAS_GICV3 to GICV3.

Suggested-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Julien Grall <julien.grall@arm.com>

---
Changes in v3:
- no changes

Changes in v2:
- patch added
---
 xen/arch/arm/Kconfig       | 4 ++--
 xen/arch/arm/Makefile      | 4 ++--
 xen/arch/arm/vgic.c        | 2 +-
 xen/arch/arm/vgic/vgic.c   | 2 +-
 xen/include/asm-arm/gic.h  | 4 ++--
 xen/include/asm-arm/vgic.h | 4 ++--
 6 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index fb69a66..66adce4 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -39,7 +39,7 @@ config ACPI
 	  Advanced Configuration and Power Interface (ACPI) support for Xen is
 	  an alternative to device tree on ARM64.
 
-config HAS_GICV3
+config GICV3
 	bool
 	prompt "GICv3 driver"
 	depends on ARM_64
@@ -52,7 +52,7 @@ config HAS_GICV3
 config HAS_ITS
         bool
         prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
-        depends on HAS_GICV3 && !NEW_VGIC
+        depends on GICV3 && !NEW_VGIC
 
 config NEW_VGIC
 	bool
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index a9533b1..b9c2fb7 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -17,7 +17,7 @@ obj-y += domctl.o
 obj-$(EARLY_PRINTK) += early_printk.o
 obj-y += gic.o
 obj-y += gic-v2.o
-obj-$(CONFIG_HAS_GICV3) += gic-v3.o
+obj-$(CONFIG_GICV3) += gic-v3.o
 obj-$(CONFIG_HAS_ITS) += gic-v3-its.o
 obj-$(CONFIG_HAS_ITS) += gic-v3-lpi.o
 obj-y += guestcopy.o
@@ -51,7 +51,7 @@ ifneq ($(CONFIG_NEW_VGIC),y)
 obj-y += gic-vgic.o
 obj-y += vgic.o
 obj-y += vgic-v2.o
-obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
+obj-$(CONFIG_GICV3) += vgic-v3.o
 obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
 endif
 obj-y += vm_event.o
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 3fafdd0..7a2c455 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -98,7 +98,7 @@ int domain_vgic_register(struct domain *d, int *mmio_count)
 {
     switch ( d->arch.vgic.version )
     {
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
     case GIC_V3:
         if ( vgic_v3_init(d, mmio_count) )
            return -ENODEV;
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index a35449b..832632a 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -974,7 +974,7 @@ unsigned int vgic_max_vcpus(const struct domain *d)
     return min_t(unsigned int, MAX_VIRT_CPUS, vgic_vcpu_limit);
 }
 
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
 /* Dummy implementation to allow building without actual vGICv3 support. */
 void vgic_v3_setup_hw(paddr_t dbase,
                       unsigned int nr_rdist_regions,
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 58b910f..22fa122 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -166,7 +166,7 @@
 
 #define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE("arm,gic-v3")
 
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
 /*
  * GICv3 registers that needs to be saved/restored
  */
@@ -194,7 +194,7 @@ struct gic_v2 {
  */
 union gic_state_data {
     struct gic_v2 v2;
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
     struct gic_v3 v3;
 #endif
 };
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 2a58ea3..374fdaa 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -156,7 +156,7 @@ struct vgic_dist {
     struct pending_irq *pending_irqs;
     /* Base address for guest GIC */
     paddr_t dbase; /* Distributor base address */
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
     /* GIC V3 addressing */
     /* List of contiguous occupied by the redistributors */
     struct vgic_rdist_region {
@@ -359,7 +359,7 @@ unsigned int vgic_max_vcpus(const struct domain *d);
 void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,
                       paddr_t vbase, uint32_t aliased_offset);
 
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
 struct rdist_region;
 void vgic_v3_setup_hw(paddr_t dbase,
                       unsigned int nr_rdist_regions,
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v6 04/13] Make MEM_ACCESS configurable
  2018-06-13 21:14 [PATCH v6 0/13] arm: more kconfig configurability and small default configs Stefano Stabellini
                   ` (2 preceding siblings ...)
  2018-06-13 21:14 ` [PATCH v6 03/13] arm: rename HAS_GICV3 to GICV3 Stefano Stabellini
@ 2018-06-13 21:14 ` Stefano Stabellini
  2018-06-22  1:51   ` Julien Grall
  2018-06-13 21:14 ` [PATCH v6 05/13] make it possible to enable/disable UART drivers Stefano Stabellini
                   ` (8 subsequent siblings)
  12 siblings, 1 reply; 29+ messages in thread
From: Stefano Stabellini @ 2018-06-13 21:14 UTC (permalink / raw)
  To: julien.grall
  Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov,
	George.Dunlap, andrew.cooper3, ian.jackson, dfaggioli, tim,
	jbeulich, wei.liu2, dgdegra, xen-devel

Select MEM_ACCESS_ALWAYS_ON on x86 to mark that MEM_ACCESS is not
configurable on x86. Avoid selecting it on ARM.
Rename HAS_MEM_ACCESS to MEM_ACCESS everywhere. Add a prompt and a
description to MEM_ACCESS in xen/common/Kconfig.

The result is that the user-visible option is MEM_ACCESS, and it is
configurable only on ARM (disabled by default). At the moment the
arch-specific mem_access code remains enabled on ARM, even with
MEM_ACCESS=y.

The purpose is to reduce code size. The option doesn't depend on EXPERT
because it would be nice to ecurity-support configurations without
MEM_ACCESS and a non-expert should be able to disable it.

Suggested-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>

CC: dgdegra@tycho.nsa.gov
CC: andrew.cooper3@citrix.com
CC: George.Dunlap@eu.citrix.com
CC: ian.jackson@eu.citrix.com
CC: jbeulich@suse.com
CC: julien.grall@arm.com
CC: konrad.wilk@oracle.com
CC: sstabellini@kernel.org
CC: tim@xen.org
CC: wei.liu2@citrix.com

---
Changes in v5:
- change MEM_ACCESS_ALWAYS_ON to bool
- change default for MEM_ACCESS, default y if MEM_ACCESS_ALWAYS_ON

Changes in v4:
- remove HAS_MEM_ACCESS
- move MEM_ACCESS_ALWAYS_ON to common
- combile default and bool to def_bool

Changes in v3:
- keep HAS_MEM_ACCESS to mark that an arch can do MEM_ACCESS
- introduce MEM_ACCESS_ALWAYS_ON
- the main MEM_ACCESS option is in xen/common/Kconfig

Changes in v2:
- patch added
---
 tools/firmware/xen-dir/shim.config |  2 +-
 xen/arch/arm/Kconfig               |  1 -
 xen/arch/x86/Kconfig               |  2 +-
 xen/common/Kconfig                 | 10 +++++++++-
 xen/common/Makefile                |  2 +-
 xen/common/domctl.c                |  2 +-
 xen/include/xen/mem_access.h       |  4 ++--
 xen/include/xsm/dummy.h            |  2 +-
 xen/include/xsm/xsm.h              |  4 ++--
 xen/xsm/dummy.c                    |  2 +-
 xen/xsm/flask/hooks.c              |  4 ++--
 11 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/tools/firmware/xen-dir/shim.config b/tools/firmware/xen-dir/shim.config
index 4d5630f..21d7075 100644
--- a/tools/firmware/xen-dir/shim.config
+++ b/tools/firmware/xen-dir/shim.config
@@ -29,7 +29,7 @@ CONFIG_COMPAT=y
 CONFIG_CORE_PARKING=y
 CONFIG_HAS_ALTERNATIVE=y
 CONFIG_HAS_EX_TABLE=y
-CONFIG_HAS_MEM_ACCESS=y
+CONFIG_MEM_ACCESS=y
 CONFIG_HAS_MEM_PAGING=y
 CONFIG_HAS_MEM_SHARING=y
 CONFIG_HAS_PDX=y
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 66adce4..2b87111 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -17,7 +17,6 @@ config ARM
 	def_bool y
 	select HAS_ALTERNATIVE
 	select HAS_DEVICE_TREE
-	select HAS_MEM_ACCESS
 	select HAS_PASSTHROUGH
 	select HAS_PDX
 
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index f64fc56..9a85fe9 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -15,7 +15,7 @@ config X86
 	select HAS_GDBSX
 	select HAS_IOPORTS
 	select HAS_KEXEC
-	select HAS_MEM_ACCESS
+	select MEM_ACCESS_ALWAYS_ON
 	select HAS_MEM_PAGING
 	select HAS_MEM_SHARING
 	select HAS_NS16550
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 9043dce..db6bb2d 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -20,9 +20,17 @@ config HAS_DEVICE_TREE
 config HAS_EX_TABLE
 	bool
 
-config HAS_MEM_ACCESS
+config MEM_ACCESS_ALWAYS_ON
 	bool
 
+config MEM_ACCESS
+	def_bool MEM_ACCESS_ALWAYS_ON
+	prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON
+	---help---
+
+	  Framework to configure memory access types for guests and receive
+	  related events in userspace.
+
 config HAS_MEM_PAGING
 	bool
 
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 24d4752..6f2b3fc 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -22,7 +22,7 @@ obj-y += lib.o
 obj-$(CONFIG_NEEDS_LIST_SORT) += list_sort.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
 obj-y += lzo.o
-obj-$(CONFIG_HAS_MEM_ACCESS) += mem_access.o
+obj-$(CONFIG_MEM_ACCESS) += mem_access.o
 obj-y += memory.o
 obj-y += monitor.o
 obj-y += multicall.o
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 9b7bc08..891ad58 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -1085,7 +1085,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         copyback = 1;
         break;
 
-#ifdef CONFIG_HAS_MEM_ACCESS
+#ifdef CONFIG_MEM_ACCESS
     case XEN_DOMCTL_set_access_required:
         if ( unlikely(current->domain == d) ) /* no domain_pause() */
             ret = -EPERM;
diff --git a/xen/include/xen/mem_access.h b/xen/include/xen/mem_access.h
index 5ab34c1..7e95eab 100644
--- a/xen/include/xen/mem_access.h
+++ b/xen/include/xen/mem_access.h
@@ -78,7 +78,7 @@ long p2m_set_mem_access_multi(struct domain *d,
  */
 int p2m_get_mem_access(struct domain *d, gfn_t gfn, xenmem_access_t *access);
 
-#ifdef CONFIG_HAS_MEM_ACCESS
+#ifdef CONFIG_MEM_ACCESS
 int mem_access_memop(unsigned long cmd,
                      XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg);
 #else
@@ -88,7 +88,7 @@ int mem_access_memop(unsigned long cmd,
 {
     return -ENOSYS;
 }
-#endif /* CONFIG_HAS_MEM_ACCESS */
+#endif /* CONFIG_MEM_ACCESS */
 
 #endif /* _XEN_MEM_ACCESS_H */
 
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index ff6b2db..b0ac1f6 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -584,7 +584,7 @@ static XSM_INLINE int xsm_vm_event_control(XSM_DEFAULT_ARG struct domain *d, int
     return xsm_default_action(action, current->domain, d);
 }
 
-#ifdef CONFIG_HAS_MEM_ACCESS
+#ifdef CONFIG_MEM_ACCESS
 static XSM_INLINE int xsm_mem_access(XSM_DEFAULT_ARG struct domain *d)
 {
     XSM_ASSERT_ACTION(XSM_DM_PRIV);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index f0c6fc7..7636bcb 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -143,7 +143,7 @@ struct xsm_operations {
 
     int (*vm_event_control) (struct domain *d, int mode, int op);
 
-#ifdef CONFIG_HAS_MEM_ACCESS
+#ifdef CONFIG_MEM_ACCESS
     int (*mem_access) (struct domain *d);
 #endif
 
@@ -582,7 +582,7 @@ static inline int xsm_vm_event_control (xsm_default_t def, struct domain *d, int
     return xsm_ops->vm_event_control(d, mode, op);
 }
 
-#ifdef CONFIG_HAS_MEM_ACCESS
+#ifdef CONFIG_MEM_ACCESS
 static inline int xsm_mem_access (xsm_default_t def, struct domain *d)
 {
     return xsm_ops->mem_access(d);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 6e75119..3290d04 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -127,7 +127,7 @@ void __init xsm_fixup_ops (struct xsm_operations *ops)
 
     set_to_dummy_if_null(ops, vm_event_control);
 
-#ifdef CONFIG_HAS_MEM_ACCESS
+#ifdef CONFIG_MEM_ACCESS
     set_to_dummy_if_null(ops, mem_access);
 #endif
 
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 78bc326..7a3ccfa 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1256,7 +1256,7 @@ static int flask_vm_event_control(struct domain *d, int mode, int op)
     return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__VM_EVENT);
 }
 
-#ifdef CONFIG_HAS_MEM_ACCESS
+#ifdef CONFIG_MEM_ACCESS
 static int flask_mem_access(struct domain *d)
 {
     return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__MEM_ACCESS);
@@ -1803,7 +1803,7 @@ static struct xsm_operations flask_ops = {
 
     .vm_event_control = flask_vm_event_control,
 
-#ifdef CONFIG_HAS_MEM_ACCESS
+#ifdef CONFIG_MEM_ACCESS
     .mem_access = flask_mem_access,
 #endif
 
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v6 05/13] make it possible to enable/disable UART drivers
  2018-06-13 21:14 [PATCH v6 0/13] arm: more kconfig configurability and small default configs Stefano Stabellini
                   ` (3 preceding siblings ...)
  2018-06-13 21:14 ` [PATCH v6 04/13] Make MEM_ACCESS configurable Stefano Stabellini
@ 2018-06-13 21:14 ` Stefano Stabellini
  2018-06-13 21:14 ` [PATCH v6 06/13] arm: make it possible to disable the SMMU driver Stefano Stabellini
                   ` (7 subsequent siblings)
  12 siblings, 0 replies; 29+ messages in thread
From: Stefano Stabellini @ 2018-06-13 21:14 UTC (permalink / raw)
  To: julien.grall
  Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
	xen-devel

All the UART drivers are silent options. Add one line descriptions so
that can be de/selected via menuconfig.

Add an x86 dependency to HAS_EHCI: EHCI PCI has not been used on ARM. In
fact, it depends on PCI, and moreover we have drivers for several
embedded UARTs for various ARM boards.

NS16550 remains not selectable on x86.

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Julien Grall <julien.grall@arm.com>
---
Changes in v4:
- improve commit message
- remove prompt for HAS_EHCI

Changes in v3:
- NS16550 prompt if ARM

Changes in v2:
- make HAS_EHCI depend on x86
---
 xen/drivers/char/Kconfig | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index cc78ec3..b1f07f8 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -1,11 +1,11 @@
 config HAS_NS16550
-	bool
+	bool "NS16550 UART driver" if ARM
 	default y
 	help
 	  This selects the 16550-series UART support. For most systems, say Y.
 
 config HAS_CADENCE_UART
-	bool
+	bool "Xilinx Cadence UART driver"
 	default y
 	depends on ARM_64
 	help
@@ -13,7 +13,7 @@ config HAS_CADENCE_UART
 	  based board, say Y.
 
 config HAS_MVEBU
-	bool
+	bool "Marvell MVEBU UART driver"
 	default y
 	depends on ARM_64
 	help
@@ -21,7 +21,7 @@ config HAS_MVEBU
 	  based board, say Y.
 
 config HAS_PL011
-	bool
+	bool "ARM PL011 UART driver"
 	default y
 	depends on ARM
 	help
@@ -29,7 +29,7 @@ config HAS_PL011
 	  an Integrator/PP2, Integrator/CP or Versatile platform, say Y.
 
 config HAS_EXYNOS4210
-	bool
+	bool "Samsung Exynos 4210 UART driver"
 	default y
 	depends on ARM_32
 	help
@@ -37,7 +37,7 @@ config HAS_EXYNOS4210
 	  Exynos based board, say Y.
 
 config HAS_OMAP
-	bool
+	bool "Texas Instruments OMAP UART driver"
 	default y
 	depends on ARM_32
 	help
@@ -45,7 +45,7 @@ config HAS_OMAP
 	  Instruments based CPU, say Y.
 
 config HAS_SCIF
-	bool
+	bool "SuperH SCI(F) UART driver"
 	default y
 	depends on ARM
 	help
@@ -54,6 +54,7 @@ config HAS_SCIF
 
 config HAS_EHCI
 	bool
+	depends on X86
 	help
 	  This selects the USB based EHCI debug port to be used as a UART. If
 	  you have an x86 based system with USB, say Y.
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v6 06/13] arm: make it possible to disable the SMMU driver
  2018-06-13 21:14 [PATCH v6 0/13] arm: more kconfig configurability and small default configs Stefano Stabellini
                   ` (4 preceding siblings ...)
  2018-06-13 21:14 ` [PATCH v6 05/13] make it possible to enable/disable UART drivers Stefano Stabellini
@ 2018-06-13 21:14 ` Stefano Stabellini
  2018-06-13 21:14 ` [PATCH v6 07/13] arm: add a tiny kconfig configuration Stefano Stabellini
                   ` (6 subsequent siblings)
  12 siblings, 0 replies; 29+ messages in thread
From: Stefano Stabellini @ 2018-06-13 21:14 UTC (permalink / raw)
  To: julien.grall
  Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
	jbeulich, xen-devel

Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver.

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Julien Grall <julien.grall@arm.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
CC: jbeulich@suse.com

---
Changes in v3:
- rename SMMUv2 to ARM_SMMU
- improve help message
- use if ARM

Changes in v2:
- rename HAS_SMMUv2 to SMMUv2
- move SMMUv2 to xen/drivers/passthrough/Kconfig
---
 xen/drivers/passthrough/Kconfig      | 12 ++++++++++++
 xen/drivers/passthrough/arm/Makefile |  2 +-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig
index 8d90b67..a3c0649 100644
--- a/xen/drivers/passthrough/Kconfig
+++ b/xen/drivers/passthrough/Kconfig
@@ -1,3 +1,15 @@
 
 config HAS_PASSTHROUGH
 	bool
+
+if ARM
+config ARM_SMMU
+	bool "ARM SMMUv1 and v2 driver"
+	default y
+	---help---
+	  Support for implementations of the ARM System MMU architecture
+	  versions 1 and 2.
+
+	  Say Y here if your SoC includes an IOMMU device implementing the
+	  ARM SMMU architecture.
+endif
diff --git a/xen/drivers/passthrough/arm/Makefile b/xen/drivers/passthrough/arm/Makefile
index f4cd26e..0156431 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1,2 @@
 obj-y += iommu.o
-obj-y += smmu.o
+obj-$(ARM_SMMU) += smmu.o
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v6 07/13] arm: add a tiny kconfig configuration
  2018-06-13 21:14 [PATCH v6 0/13] arm: more kconfig configurability and small default configs Stefano Stabellini
                   ` (5 preceding siblings ...)
  2018-06-13 21:14 ` [PATCH v6 06/13] arm: make it possible to disable the SMMU driver Stefano Stabellini
@ 2018-06-13 21:14 ` Stefano Stabellini
  2018-06-13 21:14 ` [PATCH v6 08/13] arm: add ALL, QEMU, Rcar3 and MPSoC configs Stefano Stabellini
                   ` (5 subsequent siblings)
  12 siblings, 0 replies; 29+ messages in thread
From: Stefano Stabellini @ 2018-06-13 21:14 UTC (permalink / raw)
  To: julien.grall
  Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
	xen-devel

Add a tiny kconfig configuration. Enabled NULL and Credit schedulers.
It only carries non-default options (use make menuconfig or make
olddefconfig to produce a complete .config file).

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>

---
---
 xen/arch/arm/configs/tiny64.conf | 43 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 xen/arch/arm/configs/tiny64.conf

diff --git a/xen/arch/arm/configs/tiny64.conf b/xen/arch/arm/configs/tiny64.conf
new file mode 100644
index 0000000..e9a5e65
--- /dev/null
+++ b/xen/arch/arm/configs/tiny64.conf
@@ -0,0 +1,43 @@
+CONFIG_ARM_64=y
+CONFIG_ARM=y
+
+#
+# Architecture Features
+#
+# CONFIG_GICV3 is not set
+# CONFIG_MEM_ACCESS is not set
+# CONFIG_SBSA_VUART_CONSOLE is not set
+
+#
+# Common Features
+#
+# CONFIG_TMEM is not set
+
+#
+# Schedulers
+#
+# CONFIG_SCHED_CREDIT2 is not set
+# CONFIG_SCHED_RTDS is not set
+# CONFIG_SCHED_ARINC653 is not set
+CONFIG_SCHED_NULL=y
+CONFIG_SCHED_NULL_DEFAULT=y
+CONFIG_SCHED_DEFAULT="null"
+# CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set
+
+#
+# Device Drivers
+#
+# CONFIG_HAS_NS16550 is not set
+# CONFIG_HAS_CADENCE_UART is not set
+# CONFIG_HAS_MVEBU is not set
+# CONFIG_HAS_PL011 is not set
+# CONFIG_HAS_SCIF is not set
+# CONFIG_ARM_SMMU is not set
+
+#
+# Debugging Options
+#
+# CONFIG_DEBUG is not set
+# CONFIG_FRAME_POINTER is not set
+# CONFIG_VERBOSE_DEBUG is not set
+# CONFIG_SCRUB_DEBUG is not set
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v6 08/13] arm: add ALL, QEMU, Rcar3 and MPSoC configs
  2018-06-13 21:14 [PATCH v6 0/13] arm: more kconfig configurability and small default configs Stefano Stabellini
                   ` (6 preceding siblings ...)
  2018-06-13 21:14 ` [PATCH v6 07/13] arm: add a tiny kconfig configuration Stefano Stabellini
@ 2018-06-13 21:14 ` Stefano Stabellini
  2018-06-13 21:14 ` [PATCH v6 09/13] xen: add per-platform defaults for NR_CPUS Stefano Stabellini
                   ` (4 subsequent siblings)
  12 siblings, 0 replies; 29+ messages in thread
From: Stefano Stabellini @ 2018-06-13 21:14 UTC (permalink / raw)
  To: julien.grall
  Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
	xen-devel, volodymyr_babchuk

Add a "Platform Support" choice with four kconfig options: QEMU, RCAR3,
MPSOC and ALL. They enable the required options for their hardware
platform. ALL enables all available platforms and it's the default. It
doesn't automatically select any of the related drivers, otherwise they
cannot be disabled. ALL is implemented by selecting hidden options
corresponding to QEMU, MPSOC and RCAR3.

In the case of the MPSOC that has a platform file under
arch/arm/platforms/, build the file if MPSOC.

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
CC: artem_mygaiev@epam.com
CC: volodymyr_babchuk@epam.com

---
Changes in v5:
- turn platform support into a choice
- add ALL

Changes in v4:
- fix GICv3/GICV3
- default y to all options
- build xilinx-zynqmp if MPSOC
---
 xen/arch/arm/Kconfig            |  2 ++
 xen/arch/arm/platforms/Kconfig  | 55 +++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/platforms/Makefile |  2 +-
 3 files changed, 58 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/platforms/Kconfig

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 2b87111..75cacfb 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -213,6 +213,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR
 config ARM32_HARDEN_BRANCH_PREDICTOR
     def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
 
+source "arch/arm/platforms/Kconfig"
+
 source "common/Kconfig"
 
 source "drivers/Kconfig"
diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
new file mode 100644
index 0000000..07c5930
--- /dev/null
+++ b/xen/arch/arm/platforms/Kconfig
@@ -0,0 +1,55 @@
+choice
+	prompt "Platform Support"
+	default ALL
+	---help---
+	Choose which hardware platform to enable in Xen.
+
+	If unsure, choose ALL.
+
+config ALL
+	bool "All Platforms"
+	select MPSOC_PLATFORM
+	select QEMU_PLATFORM
+	select RCAR3_PLATFORM
+	---help---
+	Enable support for all available hardware platforms. It doesn't
+	automatically select any of the related drivers.
+
+config QEMU
+	bool "QEMU aarch virt machine support"
+	depends on ARM_64
+	select QEMU_PLATFORM
+	select GICV3
+	select HAS_PL011
+	---help---
+	Enable all the required drivers for QEMU aarch64 virt emulated
+	machine.
+
+config RCAR3
+	bool "Renesas RCar3 support"
+	depends on ARM_64
+	select RCAR3_PLATFORM
+	select HAS_SCIF
+	---help---
+	Enable all the required drivers for Renesas RCar3
+
+config MPSOC
+	bool "Xilinx Ultrascale+ MPSoC support"
+	depends on ARM_64
+	select MPSOC_PLATFORM
+	select HAS_CADENCE_UART
+	select ARM_SMMU
+	---help---
+	Enable all the required drivers for Xilinx Ultrascale+ MPSoC
+
+endchoice
+
+config QEMU_PLATFORM
+	bool
+
+config RCAR3_PLATFORM
+	bool
+
+config MPSOC_PLATFORM
+	bool
+
diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 80e555c..a79bdb9 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -8,4 +8,4 @@ obj-$(CONFIG_ARM_64) += seattle.o
 obj-y += sunxi.o
 obj-$(CONFIG_ARM_64) += thunderx.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
-obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
+obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp.o
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v6 09/13] xen: add per-platform defaults for NR_CPUS
  2018-06-13 21:14 [PATCH v6 0/13] arm: more kconfig configurability and small default configs Stefano Stabellini
                   ` (7 preceding siblings ...)
  2018-06-13 21:14 ` [PATCH v6 08/13] arm: add ALL, QEMU, Rcar3 and MPSoC configs Stefano Stabellini
@ 2018-06-13 21:14 ` Stefano Stabellini
  2018-06-13 21:14 ` [PATCH v6 10/13] xen: add cloc target Stefano Stabellini
                   ` (3 subsequent siblings)
  12 siblings, 0 replies; 29+ messages in thread
From: Stefano Stabellini @ 2018-06-13 21:14 UTC (permalink / raw)
  To: julien.grall
  Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov,
	andrew.cooper3, dfaggioli, JBeulich, xen-devel

Add specific per-platform defaults for NR_CPUS. Note that the order of
the defaults matter: they need to go first, otherwise the generic
defaults will be applied.

This is done so that Xen builds customized for a specific hardware
platform can have the right NR_CPUS number.

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
CC: JBeulich@suse.com
CC: andrew.cooper3@citrix.com

---

Changes in v6:
- remove useless additional default for ALL
---
 xen/arch/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig
index cf0acb7..1954d1c 100644
--- a/xen/arch/Kconfig
+++ b/xen/arch/Kconfig
@@ -3,6 +3,9 @@ config NR_CPUS
 	int "Maximum number of physical CPUs"
 	range 1 4095
 	default "256" if X86
+	default "8" if ARM && RCAR3
+	default "4" if ARM && QEMU
+	default "4" if ARM && MPSOC
 	default "128" if ARM
 	---help---
 	  Specifies the maximum number of physical CPUs which Xen will support.
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v6 10/13] xen: add cloc target
  2018-06-13 21:14 [PATCH v6 0/13] arm: more kconfig configurability and small default configs Stefano Stabellini
                   ` (8 preceding siblings ...)
  2018-06-13 21:14 ` [PATCH v6 09/13] xen: add per-platform defaults for NR_CPUS Stefano Stabellini
@ 2018-06-13 21:14 ` Stefano Stabellini
  2018-06-13 21:14 ` [PATCH v6 11/13] xen: support the Null scheduler Stefano Stabellini
                   ` (2 subsequent siblings)
  12 siblings, 0 replies; 29+ messages in thread
From: Stefano Stabellini @ 2018-06-13 21:14 UTC (permalink / raw)
  To: julien.grall
  Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov,
	andrew.cooper3, dfaggioli, jbeulich, xen-devel

Add a Xen build target to count the lines of code of the source files
built. Uses `cloc' to do the job.

With Xen on ARM taking off in embedded, IoT, and automotive, we are
seeing more and more uses of Xen in constrained environments. Users and
system integrators want the smallest Xen and Dom0 configurations. Some
of these deployments require certifications, where you definitely want
the smallest lines of code count. I provided this patch to give us the
lines of code count for that purpose.

Use the .o.d files to account for all the built source files. Generate a
list for the `cloc' utility and invoke `cloc'.

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
CC: jbeulich@suse.com
CC: andrew.cooper3@citrix.com
---
Changes in v4:
- use grep regex to get multiple source files from .d files

Changes in v3:
- remove build as dependecy for the cloc target

Changes in v2:
- change implementation to use .o.d to find built source files
---
 xen/Makefile | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/xen/Makefile b/xen/Makefile
index 62d479c..338d5a3 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -267,3 +267,15 @@ $(KCONFIG_CONFIG):
 include/config/auto.conf.cmd: ;
 
 -include $(BASEDIR)/include/config/auto.conf.cmd
+
+.PHONY: cloc
+cloc:
+	$(eval tmpfile := $(shell mktemp))
+	$(foreach f, $(shell find $(BASEDIR) -name *.o.d), \
+		$(eval path := $(dir $(f))) \
+		$(eval names := $(shell grep -o "[a-zA-Z0-9_/-]*\.[cS]" $(f))) \
+		$(foreach sf, $(names), \
+			$(shell if test -f $(path)/$(sf) ; then echo $(path)/$(sf) >> $(tmpfile); fi;)))
+	cloc --list-file=$(tmpfile)
+	rm $(tmpfile)
+
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v6 11/13] xen: support the Null scheduler
  2018-06-13 21:14 [PATCH v6 0/13] arm: more kconfig configurability and small default configs Stefano Stabellini
                   ` (9 preceding siblings ...)
  2018-06-13 21:14 ` [PATCH v6 10/13] xen: add cloc target Stefano Stabellini
@ 2018-06-13 21:14 ` Stefano Stabellini
  2018-06-14 13:40   ` Jan Beulich
  2018-06-13 21:14 ` [PATCH v6 12/13] xen: specify support for EXPERT and DEBUG Kconfig options Stefano Stabellini
  2018-06-13 21:14 ` [PATCH v6 13/13] xen: clarify the security-support status of Kconfig options on ARM Stefano Stabellini
  12 siblings, 1 reply; 29+ messages in thread
From: Stefano Stabellini @ 2018-06-13 21:14 UTC (permalink / raw)
  To: julien.grall
  Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov,
	George.Dunlap, andrew.cooper3, Ian.Jackson, dfaggioli, jbeulich,
	xen-devel

The Null scheduler has been in the tree long enough to be marked
supported.

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
CC: George.Dunlap@eu.citrix.com
CC: Ian.Jackson@eu.citrix.com
CC: jbeulich@suse.com
CC: andrew.cooper3@citrix.com
CC: dfaggioli@suse.com
---
 SUPPORT.md         | 2 +-
 xen/common/Kconfig | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 264b23f..f96c38c 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -284,7 +284,7 @@ Currently only single-vcpu domains are supported.
 
 ### Null Scheduler
 
-    Status: Experimental
+    Status: Supported
 
 A very simple, very static scheduling policy
 that always schedules the same vCPU(s) on the same pCPU(s).
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index db6bb2d..bb1e831 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -203,7 +203,7 @@ config SCHED_ARINC653
 	  cores, targeted for avionics, drones, and medical devices.
 
 config SCHED_NULL
-	bool "Null scheduler support (EXPERIMENTAL)"
+	bool "Null scheduler support"
 	default y
 	---help---
 	  The null scheduler is a static, zero overhead scheduler,
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v6 12/13] xen: specify support for EXPERT and DEBUG Kconfig options
  2018-06-13 21:14 [PATCH v6 0/13] arm: more kconfig configurability and small default configs Stefano Stabellini
                   ` (10 preceding siblings ...)
  2018-06-13 21:14 ` [PATCH v6 11/13] xen: support the Null scheduler Stefano Stabellini
@ 2018-06-13 21:14 ` Stefano Stabellini
  2018-06-14 13:44   ` Jan Beulich
  2018-06-13 21:14 ` [PATCH v6 13/13] xen: clarify the security-support status of Kconfig options on ARM Stefano Stabellini
  12 siblings, 1 reply; 29+ messages in thread
From: Stefano Stabellini @ 2018-06-13 21:14 UTC (permalink / raw)
  To: julien.grall
  Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov,
	George.Dunlap, andrew.cooper3, Ian.Jackson, dfaggioli, jbeulich,
	xen-devel

Add a clear statement about them, reflecting the current security
support status of Kconfig options (no changes to current policies).

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
CC: George.Dunlap@eu.citrix.com
CC: Ian.Jackson@eu.citrix.com
CC: jbeulich@suse.com
CC: andrew.cooper3@citrix.com
---
 SUPPORT.md | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index f96c38c..c5ec849 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -16,6 +16,13 @@ for the definitions of the support status levels etc.
 
 # Feature Support
 
+## Kconfig
+
+Kconfig options that depend on CONFIG_EXPERT or CONFIG_DEBUG are not
+security supported. Other Kconfig options that do not depend on
+CONFIG_EXPERT or CONFIG_DEBUG are supported, if the related features are
+marked as supported in this document.
+
 ## Host Architecture
 
 ### x86-64
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [PATCH v6 13/13] xen: clarify the security-support status of Kconfig options on ARM
  2018-06-13 21:14 [PATCH v6 0/13] arm: more kconfig configurability and small default configs Stefano Stabellini
                   ` (11 preceding siblings ...)
  2018-06-13 21:14 ` [PATCH v6 12/13] xen: specify support for EXPERT and DEBUG Kconfig options Stefano Stabellini
@ 2018-06-13 21:14 ` Stefano Stabellini
  12 siblings, 0 replies; 29+ messages in thread
From: Stefano Stabellini @ 2018-06-13 21:14 UTC (permalink / raw)
  To: julien.grall
  Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov,
	George.Dunlap, andrew.cooper3, Ian.Jackson, dfaggioli, jbeulich,
	xen-devel

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
CC: George.Dunlap@eu.citrix.com
CC: Ian.Jackson@eu.citrix.com
CC: jbeulich@suse.com
CC: andrew.cooper3@citrix.com
---
 SUPPORT.md | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index c5ec849..f37a3e6 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -23,6 +23,16 @@ security supported. Other Kconfig options that do not depend on
 CONFIG_EXPERT or CONFIG_DEBUG are supported, if the related features are
 marked as supported in this document.
 
+On ARM, a wider range of Kconfig configurations is available to enable
+very small lines of code counts in the hypervisor. Not all possible
+combinations of kconfig options are security supported. Instead, a few
+pre-canned configurations have been added to xen/arch/arm/configs: they
+are security suppored. Configurations derived from the pre-canned files
+by adding non-listed options with their default values, or by enabling
+any of the platform options under "Platform Support" (and their
+dependent options) are security supported, unless stated
+otherwise.
+
 ## Host Architecture
 
 ### x86-64
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* Re: [PATCH v6 11/13] xen: support the Null scheduler
  2018-06-13 21:14 ` [PATCH v6 11/13] xen: support the Null scheduler Stefano Stabellini
@ 2018-06-14 13:40   ` Jan Beulich
  2018-06-14 13:43     ` Andrew Cooper
  0 siblings, 1 reply; 29+ messages in thread
From: Jan Beulich @ 2018-06-14 13:40 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: Artem Mygaiev, Lars Kurth, andrii_anisov, George Dunlap,
	Andrew Cooper, Ian Jackson, xen-devel, Julien Grall,
	Dario Faggioli

>>> On 13.06.18 at 23:14, <sstabellini@kernel.org> wrote:
> The Null scheduler has been in the tree long enough to be marked
> supported.

Wasn't there at least one problem pointed out with it that last time
is was proposed to mark it supported (not overly long ago)?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v6 11/13] xen: support the Null scheduler
  2018-06-14 13:40   ` Jan Beulich
@ 2018-06-14 13:43     ` Andrew Cooper
  2018-06-14 20:20       ` Stefano Stabellini
  0 siblings, 1 reply; 29+ messages in thread
From: Andrew Cooper @ 2018-06-14 13:43 UTC (permalink / raw)
  To: Jan Beulich, Stefano Stabellini
  Cc: Artem Mygaiev, Lars Kurth, andrii_anisov, George Dunlap,
	Ian Jackson, xen-devel, Julien Grall, Dario Faggioli

On 14/06/18 14:40, Jan Beulich wrote:
>>>> On 13.06.18 at 23:14, <sstabellini@kernel.org> wrote:
>> The Null scheduler has been in the tree long enough to be marked
>> supported.
> Wasn't there at least one problem pointed out with it that last time
> is was proposed to mark it supported (not overly long ago)?

The PV-shim work has identified that there are definitely functional
problems with the Null scheduler.  ISTR that after a while, vcpus just
ceased to be scheduled.

I don't think its reasonable to alter the support status with this issue
outstanding.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v6 12/13] xen: specify support for EXPERT and DEBUG Kconfig options
  2018-06-13 21:14 ` [PATCH v6 12/13] xen: specify support for EXPERT and DEBUG Kconfig options Stefano Stabellini
@ 2018-06-14 13:44   ` Jan Beulich
  2018-06-14 20:22     ` Stefano Stabellini
  0 siblings, 1 reply; 29+ messages in thread
From: Jan Beulich @ 2018-06-14 13:44 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: Artem Mygaiev, Lars Kurth, andrii_anisov, George Dunlap,
	Andrew Cooper, Ian Jackson, xen-devel, Julien Grall,
	Dario Faggioli

>>> On 13.06.18 at 23:14, <sstabellini@kernel.org> wrote:
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -16,6 +16,13 @@ for the definitions of the support status levels etc.
>  
>  # Feature Support
>  
> +## Kconfig
> +
> +Kconfig options that depend on CONFIG_EXPERT or CONFIG_DEBUG are not
> +security supported. Other Kconfig options that do not depend on
> +CONFIG_EXPERT or CONFIG_DEBUG are supported, if the related features are
> +marked as supported in this document.

Generally fine with me, except there's no CONFIG_EXPERT. EXPERT is a special
setting that comes from the environment. Hence also the non-standard
EXPERT = "y" checks. Perhaps better to talk about the "EXPERT and DEBUG
Kconfig options".

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v6 11/13] xen: support the Null scheduler
  2018-06-14 13:43     ` Andrew Cooper
@ 2018-06-14 20:20       ` Stefano Stabellini
  2018-06-28  7:27         ` Dario Faggioli
  0 siblings, 1 reply; 29+ messages in thread
From: Stefano Stabellini @ 2018-06-14 20:20 UTC (permalink / raw)
  To: Andrew Cooper
  Cc: Artem Mygaiev, Lars Kurth, Stefano Stabellini, andrii_anisov,
	George Dunlap, Ian Jackson, xen-devel, Julien Grall, Jan Beulich,
	Dario Faggioli

[-- Attachment #1: Type: TEXT/PLAIN, Size: 945 bytes --]

On Thu, 14 Jun 2018, Andrew Cooper wrote:
> On 14/06/18 14:40, Jan Beulich wrote:
> >>>> On 13.06.18 at 23:14, <sstabellini@kernel.org> wrote:
> >> The Null scheduler has been in the tree long enough to be marked
> >> supported.
> > Wasn't there at least one problem pointed out with it that last time
> > is was proposed to mark it supported (not overly long ago)?
> 
> The PV-shim work has identified that there are definitely functional
> problems with the Null scheduler.  ISTR that after a while, vcpus just
> ceased to be scheduled.
> 
> I don't think its reasonable to alter the support status with this issue
> outstanding.

I completely missed this report, probably because I haven't paid
attention to PV-shim. Do you have any more information about this? The
report is a bit vague. If I can't repro it, I can't fix it.

Couldn't it be that is normal because after a while you ran out of
pcpus?

Dario, do you have any opinion on this?

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v6 12/13] xen: specify support for EXPERT and DEBUG Kconfig options
  2018-06-14 13:44   ` Jan Beulich
@ 2018-06-14 20:22     ` Stefano Stabellini
  0 siblings, 0 replies; 29+ messages in thread
From: Stefano Stabellini @ 2018-06-14 20:22 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Artem Mygaiev, Lars Kurth, Stefano Stabellini, andrii_anisov,
	George Dunlap, Andrew Cooper, Ian Jackson, xen-devel,
	Julien Grall, Dario Faggioli

On Thu, 14 Jun 2018, Jan Beulich wrote:
> >>> On 13.06.18 at 23:14, <sstabellini@kernel.org> wrote:
> > --- a/SUPPORT.md
> > +++ b/SUPPORT.md
> > @@ -16,6 +16,13 @@ for the definitions of the support status levels etc.
> >  
> >  # Feature Support
> >  
> > +## Kconfig
> > +
> > +Kconfig options that depend on CONFIG_EXPERT or CONFIG_DEBUG are not
> > +security supported. Other Kconfig options that do not depend on
> > +CONFIG_EXPERT or CONFIG_DEBUG are supported, if the related features are
> > +marked as supported in this document.
> 
> Generally fine with me, except there's no CONFIG_EXPERT. EXPERT is a special
> setting that comes from the environment. Hence also the non-standard
> EXPERT = "y" checks. Perhaps better to talk about the "EXPERT and DEBUG
> Kconfig options".

I'll reword as suggested.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v6 04/13] Make MEM_ACCESS configurable
  2018-06-13 21:14 ` [PATCH v6 04/13] Make MEM_ACCESS configurable Stefano Stabellini
@ 2018-06-22  1:51   ` Julien Grall
  0 siblings, 0 replies; 29+ messages in thread
From: Julien Grall @ 2018-06-22  1:51 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: artem_mygaiev, lars.kurth, andrii_anisov, George.Dunlap,
	andrew.cooper3, ian.jackson, dfaggioli, tim, jbeulich, wei.liu2,
	dgdegra, xen-devel

Hi Stefano,

On 06/13/2018 10:14 PM, Stefano Stabellini wrote:
> Select MEM_ACCESS_ALWAYS_ON on x86 to mark that MEM_ACCESS is not
> configurable on x86. Avoid selecting it on ARM.
> Rename HAS_MEM_ACCESS to MEM_ACCESS everywhere. Add a prompt and a
> description to MEM_ACCESS in xen/common/Kconfig.
> 
> The result is that the user-visible option is MEM_ACCESS, and it is
> configurable only on ARM (disabled by default). At the moment the
> arch-specific mem_access code remains enabled on ARM, even with
> MEM_ACCESS=y.
> 
> The purpose is to reduce code size. The option doesn't depend on EXPERT
> because it would be nice to ecurity-support configurations without
> MEM_ACCESS and a non-expert should be able to disable it.
> 
> Suggested-by: Julien Grall <julien.grall@arm.com>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> Acked-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Julien Grall <julien.grall@arm.com>

Cheers,

> 
> CC: dgdegra@tycho.nsa.gov
> CC: andrew.cooper3@citrix.com
> CC: George.Dunlap@eu.citrix.com
> CC: ian.jackson@eu.citrix.com
> CC: jbeulich@suse.com
> CC: julien.grall@arm.com
> CC: konrad.wilk@oracle.com
> CC: sstabellini@kernel.org
> CC: tim@xen.org
> CC: wei.liu2@citrix.com
> 
> ---
> Changes in v5:
> - change MEM_ACCESS_ALWAYS_ON to bool
> - change default for MEM_ACCESS, default y if MEM_ACCESS_ALWAYS_ON
> 
> Changes in v4:
> - remove HAS_MEM_ACCESS
> - move MEM_ACCESS_ALWAYS_ON to common
> - combile default and bool to def_bool
> 
> Changes in v3:
> - keep HAS_MEM_ACCESS to mark that an arch can do MEM_ACCESS
> - introduce MEM_ACCESS_ALWAYS_ON
> - the main MEM_ACCESS option is in xen/common/Kconfig
> 
> Changes in v2:
> - patch added
> ---
>   tools/firmware/xen-dir/shim.config |  2 +-
>   xen/arch/arm/Kconfig               |  1 -
>   xen/arch/x86/Kconfig               |  2 +-
>   xen/common/Kconfig                 | 10 +++++++++-
>   xen/common/Makefile                |  2 +-
>   xen/common/domctl.c                |  2 +-
>   xen/include/xen/mem_access.h       |  4 ++--
>   xen/include/xsm/dummy.h            |  2 +-
>   xen/include/xsm/xsm.h              |  4 ++--
>   xen/xsm/dummy.c                    |  2 +-
>   xen/xsm/flask/hooks.c              |  4 ++--
>   11 files changed, 21 insertions(+), 14 deletions(-)
> 
> diff --git a/tools/firmware/xen-dir/shim.config b/tools/firmware/xen-dir/shim.config
> index 4d5630f..21d7075 100644
> --- a/tools/firmware/xen-dir/shim.config
> +++ b/tools/firmware/xen-dir/shim.config
> @@ -29,7 +29,7 @@ CONFIG_COMPAT=y
>   CONFIG_CORE_PARKING=y
>   CONFIG_HAS_ALTERNATIVE=y
>   CONFIG_HAS_EX_TABLE=y
> -CONFIG_HAS_MEM_ACCESS=y
> +CONFIG_MEM_ACCESS=y
>   CONFIG_HAS_MEM_PAGING=y
>   CONFIG_HAS_MEM_SHARING=y
>   CONFIG_HAS_PDX=y
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 66adce4..2b87111 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -17,7 +17,6 @@ config ARM
>   	def_bool y
>   	select HAS_ALTERNATIVE
>   	select HAS_DEVICE_TREE
> -	select HAS_MEM_ACCESS
>   	select HAS_PASSTHROUGH
>   	select HAS_PDX
>   
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index f64fc56..9a85fe9 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -15,7 +15,7 @@ config X86
>   	select HAS_GDBSX
>   	select HAS_IOPORTS
>   	select HAS_KEXEC
> -	select HAS_MEM_ACCESS
> +	select MEM_ACCESS_ALWAYS_ON
>   	select HAS_MEM_PAGING
>   	select HAS_MEM_SHARING
>   	select HAS_NS16550
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 9043dce..db6bb2d 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -20,9 +20,17 @@ config HAS_DEVICE_TREE
>   config HAS_EX_TABLE
>   	bool
>   
> -config HAS_MEM_ACCESS
> +config MEM_ACCESS_ALWAYS_ON
>   	bool
>   
> +config MEM_ACCESS
> +	def_bool MEM_ACCESS_ALWAYS_ON
> +	prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON
> +	---help---
> +
> +	  Framework to configure memory access types for guests and receive
> +	  related events in userspace.
> +
>   config HAS_MEM_PAGING
>   	bool
>   
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 24d4752..6f2b3fc 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -22,7 +22,7 @@ obj-y += lib.o
>   obj-$(CONFIG_NEEDS_LIST_SORT) += list_sort.o
>   obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
>   obj-y += lzo.o
> -obj-$(CONFIG_HAS_MEM_ACCESS) += mem_access.o
> +obj-$(CONFIG_MEM_ACCESS) += mem_access.o
>   obj-y += memory.o
>   obj-y += monitor.o
>   obj-y += multicall.o
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index 9b7bc08..891ad58 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -1085,7 +1085,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>           copyback = 1;
>           break;
>   
> -#ifdef CONFIG_HAS_MEM_ACCESS
> +#ifdef CONFIG_MEM_ACCESS
>       case XEN_DOMCTL_set_access_required:
>           if ( unlikely(current->domain == d) ) /* no domain_pause() */
>               ret = -EPERM;
> diff --git a/xen/include/xen/mem_access.h b/xen/include/xen/mem_access.h
> index 5ab34c1..7e95eab 100644
> --- a/xen/include/xen/mem_access.h
> +++ b/xen/include/xen/mem_access.h
> @@ -78,7 +78,7 @@ long p2m_set_mem_access_multi(struct domain *d,
>    */
>   int p2m_get_mem_access(struct domain *d, gfn_t gfn, xenmem_access_t *access);
>   
> -#ifdef CONFIG_HAS_MEM_ACCESS
> +#ifdef CONFIG_MEM_ACCESS
>   int mem_access_memop(unsigned long cmd,
>                        XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg);
>   #else
> @@ -88,7 +88,7 @@ int mem_access_memop(unsigned long cmd,
>   {
>       return -ENOSYS;
>   }
> -#endif /* CONFIG_HAS_MEM_ACCESS */
> +#endif /* CONFIG_MEM_ACCESS */
>   
>   #endif /* _XEN_MEM_ACCESS_H */
>   
> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
> index ff6b2db..b0ac1f6 100644
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -584,7 +584,7 @@ static XSM_INLINE int xsm_vm_event_control(XSM_DEFAULT_ARG struct domain *d, int
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -#ifdef CONFIG_HAS_MEM_ACCESS
> +#ifdef CONFIG_MEM_ACCESS
>   static XSM_INLINE int xsm_mem_access(XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> index f0c6fc7..7636bcb 100644
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -143,7 +143,7 @@ struct xsm_operations {
>   
>       int (*vm_event_control) (struct domain *d, int mode, int op);
>   
> -#ifdef CONFIG_HAS_MEM_ACCESS
> +#ifdef CONFIG_MEM_ACCESS
>       int (*mem_access) (struct domain *d);
>   #endif
>   
> @@ -582,7 +582,7 @@ static inline int xsm_vm_event_control (xsm_default_t def, struct domain *d, int
>       return xsm_ops->vm_event_control(d, mode, op);
>   }
>   
> -#ifdef CONFIG_HAS_MEM_ACCESS
> +#ifdef CONFIG_MEM_ACCESS
>   static inline int xsm_mem_access (xsm_default_t def, struct domain *d)
>   {
>       return xsm_ops->mem_access(d);
> diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
> index 6e75119..3290d04 100644
> --- a/xen/xsm/dummy.c
> +++ b/xen/xsm/dummy.c
> @@ -127,7 +127,7 @@ void __init xsm_fixup_ops (struct xsm_operations *ops)
>   
>       set_to_dummy_if_null(ops, vm_event_control);
>   
> -#ifdef CONFIG_HAS_MEM_ACCESS
> +#ifdef CONFIG_MEM_ACCESS
>       set_to_dummy_if_null(ops, mem_access);
>   #endif
>   
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 78bc326..7a3ccfa 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1256,7 +1256,7 @@ static int flask_vm_event_control(struct domain *d, int mode, int op)
>       return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__VM_EVENT);
>   }
>   
> -#ifdef CONFIG_HAS_MEM_ACCESS
> +#ifdef CONFIG_MEM_ACCESS
>   static int flask_mem_access(struct domain *d)
>   {
>       return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__MEM_ACCESS);
> @@ -1803,7 +1803,7 @@ static struct xsm_operations flask_ops = {
>   
>       .vm_event_control = flask_vm_event_control,
>   
> -#ifdef CONFIG_HAS_MEM_ACCESS
> +#ifdef CONFIG_MEM_ACCESS
>       .mem_access = flask_mem_access,
>   #endif
>   
> 

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v6 11/13] xen: support the Null scheduler
  2018-06-14 20:20       ` Stefano Stabellini
@ 2018-06-28  7:27         ` Dario Faggioli
  2018-06-28  7:36           ` Roger Pau Monné
  0 siblings, 1 reply; 29+ messages in thread
From: Dario Faggioli @ 2018-06-28  7:27 UTC (permalink / raw)
  To: Stefano Stabellini, Andrew Cooper
  Cc: Artem Mygaiev, Lars Kurth, andrii_anisov, George Dunlap,
	Ian Jackson, xen-devel, Julien Grall, Jan Beulich,
	Roger Pau Monne


[-- Attachment #1.1: Type: text/plain, Size: 1674 bytes --]

On Thu, 2018-06-14 at 13:20 -0700, Stefano Stabellini wrote:
> On Thu, 14 Jun 2018, Andrew Cooper wrote:
> > On 14/06/18 14:40, Jan Beulich wrote:
> > I don't think its reasonable to alter the support status with this
> issue
> > outstanding.
> 
> I completely missed this report, probably because I haven't paid
> attention to PV-shim. Do you have any more information about this?
> The
> report is a bit vague. If I can't repro it, I can't fix it.
> 
> Couldn't it be that is normal because after a while you ran out of
> pcpus?
> 
> Dario, do you have any opinion on this?
>
The issue that I know of is that the null scheduler does not properly
support CPU hotplug/hotunplug.

This is an issue on, let's say, baremetal, if you use null, and try to
do CPU hotplug/hotunplug. When trying to use null as the scheduler of
the shim, we run into that same issue, even if not specifically doing
CPU hotplug/hotunplug (because the shim use the same path for CPU
bringup, IIRC).

In fact, I'm Cc-ing Roger as he's the one that found out the issue, and
we've discussed already a plan to fix it (that was mostly on IRC, so I
don't have a link, sorry).

FWIW, I am a little bit pressed with something right now, but fixing
this is very high in my todo list.

I think we should definitely aim at having null as supported for 4.12,
but I wouldn't mark it as such with known outstanding bugs.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v6 11/13] xen: support the Null scheduler
  2018-06-28  7:27         ` Dario Faggioli
@ 2018-06-28  7:36           ` Roger Pau Monné
  2018-06-29 18:38             ` Stefano Stabellini
  0 siblings, 1 reply; 29+ messages in thread
From: Roger Pau Monné @ 2018-06-28  7:36 UTC (permalink / raw)
  To: Dario Faggioli
  Cc: Artem Mygaiev, Lars Kurth, Stefano Stabellini, andrii_anisov,
	George Dunlap, Andrew Cooper, Ian Jackson, xen-devel,
	Julien Grall, Jan Beulich

On Thu, Jun 28, 2018 at 09:27:08AM +0200, Dario Faggioli wrote:
> On Thu, 2018-06-14 at 13:20 -0700, Stefano Stabellini wrote:
> > On Thu, 14 Jun 2018, Andrew Cooper wrote:
> > > On 14/06/18 14:40, Jan Beulich wrote:
> > > I don't think its reasonable to alter the support status with this
> > issue
> > > outstanding.
> > 
> > I completely missed this report, probably because I haven't paid
> > attention to PV-shim. Do you have any more information about this?
> > The
> > report is a bit vague. If I can't repro it, I can't fix it.
> > 
> > Couldn't it be that is normal because after a while you ran out of
> > pcpus?
> > 
> > Dario, do you have any opinion on this?
> >
> The issue that I know of is that the null scheduler does not properly
> support CPU hotplug/hotunplug.
> 
> This is an issue on, let's say, baremetal, if you use null, and try to
> do CPU hotplug/hotunplug. When trying to use null as the scheduler of
> the shim, we run into that same issue, even if not specifically doing
> CPU hotplug/hotunplug (because the shim use the same path for CPU
> bringup, IIRC).

The shim uses CPU hotplug/unplug when the guest brings up/down a
vCPU using the VCPUOP_{up/down} hypercall.

The best description of the issue I could find is:

https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg01085.html

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v6 11/13] xen: support the Null scheduler
  2018-06-28  7:36           ` Roger Pau Monné
@ 2018-06-29 18:38             ` Stefano Stabellini
  2018-07-02 11:31               ` Julien Grall
  0 siblings, 1 reply; 29+ messages in thread
From: Stefano Stabellini @ 2018-06-29 18:38 UTC (permalink / raw)
  To: Roger Pau Monné
  Cc: Artem Mygaiev, Lars Kurth, Stefano Stabellini, andrii_anisov,
	George Dunlap, Andrew Cooper, Ian Jackson, Dario Faggioli,
	Julien Grall, Jan Beulich, xen-devel

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1674 bytes --]

On Thu, 28 Jun 2018, Roger Pau Monné wrote:
> On Thu, Jun 28, 2018 at 09:27:08AM +0200, Dario Faggioli wrote:
> > On Thu, 2018-06-14 at 13:20 -0700, Stefano Stabellini wrote:
> > > On Thu, 14 Jun 2018, Andrew Cooper wrote:
> > > > On 14/06/18 14:40, Jan Beulich wrote:
> > > > I don't think its reasonable to alter the support status with this
> > > issue
> > > > outstanding.
> > > 
> > > I completely missed this report, probably because I haven't paid
> > > attention to PV-shim. Do you have any more information about this?
> > > The
> > > report is a bit vague. If I can't repro it, I can't fix it.
> > > 
> > > Couldn't it be that is normal because after a while you ran out of
> > > pcpus?
> > > 
> > > Dario, do you have any opinion on this?
> > >
> > The issue that I know of is that the null scheduler does not properly
> > support CPU hotplug/hotunplug.
> > 
> > This is an issue on, let's say, baremetal, if you use null, and try to
> > do CPU hotplug/hotunplug. When trying to use null as the scheduler of
> > the shim, we run into that same issue, even if not specifically doing
> > CPU hotplug/hotunplug (because the shim use the same path for CPU
> > bringup, IIRC).
> 
> The shim uses CPU hotplug/unplug when the guest brings up/down a
> vCPU using the VCPUOP_{up/down} hypercall.
> 
> The best description of the issue I could find is:
> 
> https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg01085.html

OK, thanks for the explanation. We don't support CPU hotplug on ARM, so
we could mark the NULL scheduler as supported on the ARM architecture
today? Once you implement CPU hotplug support in NULL, we could mark it
as supported on x86 too.

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v6 11/13] xen: support the Null scheduler
  2018-06-29 18:38             ` Stefano Stabellini
@ 2018-07-02 11:31               ` Julien Grall
  2018-07-02 18:24                 ` Stefano Stabellini
  0 siblings, 1 reply; 29+ messages in thread
From: Julien Grall @ 2018-07-02 11:31 UTC (permalink / raw)
  To: Stefano Stabellini, Roger Pau Monné
  Cc: Artem Mygaiev, Lars Kurth, andrii_anisov, George Dunlap,
	Andrew Cooper, Ian Jackson, Dario Faggioli, Jan Beulich,
	xen-devel

Hi Stefano,

On 06/29/2018 07:38 PM, Stefano Stabellini wrote:
> On Thu, 28 Jun 2018, Roger Pau Monné wrote:
>> On Thu, Jun 28, 2018 at 09:27:08AM +0200, Dario Faggioli wrote:
>>> On Thu, 2018-06-14 at 13:20 -0700, Stefano Stabellini wrote:
>>>> On Thu, 14 Jun 2018, Andrew Cooper wrote:
>>>>> On 14/06/18 14:40, Jan Beulich wrote:
>>>>> I don't think its reasonable to alter the support status with this
>>>> issue
>>>>> outstanding.
>>>>
>>>> I completely missed this report, probably because I haven't paid
>>>> attention to PV-shim. Do you have any more information about this?
>>>> The
>>>> report is a bit vague. If I can't repro it, I can't fix it.
>>>>
>>>> Couldn't it be that is normal because after a while you ran out of
>>>> pcpus?
>>>>
>>>> Dario, do you have any opinion on this?
>>>>
>>> The issue that I know of is that the null scheduler does not properly
>>> support CPU hotplug/hotunplug.
>>>
>>> This is an issue on, let's say, baremetal, if you use null, and try to
>>> do CPU hotplug/hotunplug. When trying to use null as the scheduler of
>>> the shim, we run into that same issue, even if not specifically doing
>>> CPU hotplug/hotunplug (because the shim use the same path for CPU
>>> bringup, IIRC).
>>
>> The shim uses CPU hotplug/unplug when the guest brings up/down a
>> vCPU using the VCPUOP_{up/down} hypercall.
>>
>> The best description of the issue I could find is:
>>
>> https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg01085.html
> 
> OK, thanks for the explanation. We don't support CPU hotplug on ARM, so
> we could mark the NULL scheduler as supported on the ARM architecture
> today? Once you implement CPU hotplug support in NULL, we could mark it
> as supported on x86 too.
Well, Mirela paved the way to support CPU hotplug (should be merged 
soon). She is looking at suspend/resume which is IHMO an extension of 
hotplug case. So are you sure this could never happen on Arm?

Also, supporting the hypercall would basically be ~20 lines. So I don't 
feel it is right to mark NULL scheduler supported on Arm until that is 
fixed in a way or another.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v6 11/13] xen: support the Null scheduler
  2018-07-02 11:31               ` Julien Grall
@ 2018-07-02 18:24                 ` Stefano Stabellini
  2018-07-02 21:07                   ` Julien Grall
  0 siblings, 1 reply; 29+ messages in thread
From: Stefano Stabellini @ 2018-07-02 18:24 UTC (permalink / raw)
  To: Julien Grall
  Cc: Artem Mygaiev, Lars Kurth, Stefano Stabellini, andrii_anisov,
	George Dunlap, Andrew Cooper, Ian Jackson, Dario Faggioli,
	Jan Beulich, xen-devel, Roger Pau Monné

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2500 bytes --]

On Mon, 2 Jul 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 06/29/2018 07:38 PM, Stefano Stabellini wrote:
> > On Thu, 28 Jun 2018, Roger Pau Monné wrote:
> > > On Thu, Jun 28, 2018 at 09:27:08AM +0200, Dario Faggioli wrote:
> > > > On Thu, 2018-06-14 at 13:20 -0700, Stefano Stabellini wrote:
> > > > > On Thu, 14 Jun 2018, Andrew Cooper wrote:
> > > > > > On 14/06/18 14:40, Jan Beulich wrote:
> > > > > > I don't think its reasonable to alter the support status with this
> > > > > issue
> > > > > > outstanding.
> > > > > 
> > > > > I completely missed this report, probably because I haven't paid
> > > > > attention to PV-shim. Do you have any more information about this?
> > > > > The
> > > > > report is a bit vague. If I can't repro it, I can't fix it.
> > > > > 
> > > > > Couldn't it be that is normal because after a while you ran out of
> > > > > pcpus?
> > > > > 
> > > > > Dario, do you have any opinion on this?
> > > > > 
> > > > The issue that I know of is that the null scheduler does not properly
> > > > support CPU hotplug/hotunplug.
> > > > 
> > > > This is an issue on, let's say, baremetal, if you use null, and try to
> > > > do CPU hotplug/hotunplug. When trying to use null as the scheduler of
> > > > the shim, we run into that same issue, even if not specifically doing
> > > > CPU hotplug/hotunplug (because the shim use the same path for CPU
> > > > bringup, IIRC).
> > > 
> > > The shim uses CPU hotplug/unplug when the guest brings up/down a
> > > vCPU using the VCPUOP_{up/down} hypercall.
> > > 
> > > The best description of the issue I could find is:
> > > 
> > > https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg01085.html
> > 
> > OK, thanks for the explanation. We don't support CPU hotplug on ARM, so
> > we could mark the NULL scheduler as supported on the ARM architecture
> > today? Once you implement CPU hotplug support in NULL, we could mark it
> > as supported on x86 too.
> Well, Mirela paved the way to support CPU hotplug (should be merged soon). She
> is looking at suspend/resume which is IHMO an extension of hotplug case. So
> are you sure this could never happen on Arm?

I thought that suspend/resume didn't actually require the same kind of
scheduler support that CPU hotplug needs. If suspend/resume ends up
not working with scheduler NULL, then that is a problem.

Real CPU hotplug is unlikely though -- do you know of any ARM platforms
that support it? Doesn't it require an actual board with physically
pluggable CPUs?

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v6 11/13] xen: support the Null scheduler
  2018-07-02 18:24                 ` Stefano Stabellini
@ 2018-07-02 21:07                   ` Julien Grall
  2018-07-02 22:08                     ` Stefano Stabellini
  0 siblings, 1 reply; 29+ messages in thread
From: Julien Grall @ 2018-07-02 21:07 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: Artem Mygaiev, Lars Kurth, xen-devel, andrii_anisov,
	George Dunlap, Andrew Cooper, Ian Jackson, Dario Faggioli,
	Jan Beulich, nd, Roger Pau Monné

Hi,

On 02/07/2018 19:24, Stefano Stabellini wrote:
> On Mon, 2 Jul 2018, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 06/29/2018 07:38 PM, Stefano Stabellini wrote:
>>> On Thu, 28 Jun 2018, Roger Pau Monné wrote:
>>>> On Thu, Jun 28, 2018 at 09:27:08AM +0200, Dario Faggioli wrote:
>>>>> On Thu, 2018-06-14 at 13:20 -0700, Stefano Stabellini wrote:
>>>>>> On Thu, 14 Jun 2018, Andrew Cooper wrote:
>>>>>>> On 14/06/18 14:40, Jan Beulich wrote:
>>>>>>> I don't think its reasonable to alter the support status with this
>>>>>> issue
>>>>>>> outstanding.
>>>>>>
>>>>>> I completely missed this report, probably because I haven't paid
>>>>>> attention to PV-shim. Do you have any more information about this?
>>>>>> The
>>>>>> report is a bit vague. If I can't repro it, I can't fix it.
>>>>>>
>>>>>> Couldn't it be that is normal because after a while you ran out of
>>>>>> pcpus?
>>>>>>
>>>>>> Dario, do you have any opinion on this?
>>>>>>
>>>>> The issue that I know of is that the null scheduler does not properly
>>>>> support CPU hotplug/hotunplug.
>>>>>
>>>>> This is an issue on, let's say, baremetal, if you use null, and try to
>>>>> do CPU hotplug/hotunplug. When trying to use null as the scheduler of
>>>>> the shim, we run into that same issue, even if not specifically doing
>>>>> CPU hotplug/hotunplug (because the shim use the same path for CPU
>>>>> bringup, IIRC).
>>>>
>>>> The shim uses CPU hotplug/unplug when the guest brings up/down a
>>>> vCPU using the VCPUOP_{up/down} hypercall.
>>>>
>>>> The best description of the issue I could find is:
>>>>
>>>> https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg01085.html
>>>
>>> OK, thanks for the explanation. We don't support CPU hotplug on ARM, so
>>> we could mark the NULL scheduler as supported on the ARM architecture
>>> today? Once you implement CPU hotplug support in NULL, we could mark it
>>> as supported on x86 too.
>> Well, Mirela paved the way to support CPU hotplug (should be merged soon). She
>> is looking at suspend/resume which is IHMO an extension of hotplug case. So
>> are you sure this could never happen on Arm?
> 
> I thought that suspend/resume didn't actually require the same kind of
> scheduler support that CPU hotplug needs. If suspend/resume ends up
> not working with scheduler NULL, then that is a problem.

The suspend/resume code will offline the CPU one by one using cpu_down. 
This is the same path as hotplug. So you will end up with more vCPUs 
than online pCPUs, although the domain will be frozen. How this is going 
to fit in the NULL scheduler?

> 
> Real CPU hotplug is unlikely though -- do you know of any ARM platforms
> that support it? Doesn't it require an actual board with physically
> pluggable CPUs?

Virtually every platform support CPU hotplug. It is not just about 
"physically pluggable CPUs" but any CPU that can be offline at any time.

Because Xen on Arm will always bring-up all the CPUs, a user may want to 
offline some of them if he knows they are not going to be used for a while.

In any case a scheduler is common code. IHMO, we should (security) 
support it on the basis that all "scheduling" features are present. Not 
on an architecture basis.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v6 11/13] xen: support the Null scheduler
  2018-07-02 21:07                   ` Julien Grall
@ 2018-07-02 22:08                     ` Stefano Stabellini
  2018-07-03 11:10                       ` Julien Grall
  0 siblings, 1 reply; 29+ messages in thread
From: Stefano Stabellini @ 2018-07-02 22:08 UTC (permalink / raw)
  To: Julien Grall
  Cc: Artem Mygaiev, Lars Kurth, nd, Stefano Stabellini, andrii_anisov,
	George Dunlap, Andrew Cooper, Ian Jackson, xen-devel,
	Jan Beulich, Dario Faggioli, Roger Pau Monné

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3752 bytes --]

On Mon, 2 Jul 2018, Julien Grall wrote:
> Hi,
> 
> On 02/07/2018 19:24, Stefano Stabellini wrote:
> > On Mon, 2 Jul 2018, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 06/29/2018 07:38 PM, Stefano Stabellini wrote:
> > > > On Thu, 28 Jun 2018, Roger Pau Monné wrote:
> > > > > On Thu, Jun 28, 2018 at 09:27:08AM +0200, Dario Faggioli wrote:
> > > > > > On Thu, 2018-06-14 at 13:20 -0700, Stefano Stabellini wrote:
> > > > > > > On Thu, 14 Jun 2018, Andrew Cooper wrote:
> > > > > > > > On 14/06/18 14:40, Jan Beulich wrote:
> > > > > > > > I don't think its reasonable to alter the support status with
> > > > > > > > this
> > > > > > > issue
> > > > > > > > outstanding.
> > > > > > > 
> > > > > > > I completely missed this report, probably because I haven't paid
> > > > > > > attention to PV-shim. Do you have any more information about this?
> > > > > > > The
> > > > > > > report is a bit vague. If I can't repro it, I can't fix it.
> > > > > > > 
> > > > > > > Couldn't it be that is normal because after a while you ran out of
> > > > > > > pcpus?
> > > > > > > 
> > > > > > > Dario, do you have any opinion on this?
> > > > > > > 
> > > > > > The issue that I know of is that the null scheduler does not
> > > > > > properly
> > > > > > support CPU hotplug/hotunplug.
> > > > > > 
> > > > > > This is an issue on, let's say, baremetal, if you use null, and try
> > > > > > to
> > > > > > do CPU hotplug/hotunplug. When trying to use null as the scheduler
> > > > > > of
> > > > > > the shim, we run into that same issue, even if not specifically
> > > > > > doing
> > > > > > CPU hotplug/hotunplug (because the shim use the same path for CPU
> > > > > > bringup, IIRC).
> > > > > 
> > > > > The shim uses CPU hotplug/unplug when the guest brings up/down a
> > > > > vCPU using the VCPUOP_{up/down} hypercall.
> > > > > 
> > > > > The best description of the issue I could find is:
> > > > > 
> > > > > https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg01085.html
> > > > 
> > > > OK, thanks for the explanation. We don't support CPU hotplug on ARM, so
> > > > we could mark the NULL scheduler as supported on the ARM architecture
> > > > today? Once you implement CPU hotplug support in NULL, we could mark it
> > > > as supported on x86 too.
> > > Well, Mirela paved the way to support CPU hotplug (should be merged soon).
> > > She
> > > is looking at suspend/resume which is IHMO an extension of hotplug case.
> > > So
> > > are you sure this could never happen on Arm?
> > 
> > I thought that suspend/resume didn't actually require the same kind of
> > scheduler support that CPU hotplug needs. If suspend/resume ends up
> > not working with scheduler NULL, then that is a problem.
> 
> The suspend/resume code will offline the CPU one by one using cpu_down. This
> is the same path as hotplug. So you will end up with more vCPUs than online
> pCPUs, although the domain will be frozen. How this is going to fit in the
> NULL scheduler?

[...]

> Virtually every platform support CPU hotplug. It is not just about "physically
> pluggable CPUs" but any CPU that can be offline at any time.

CPU hotplug in Xen clearly doesn't work as I expected: I assumed that
CPU hotplug would make a CPU "present" or "absent", while cpu_up/down
would make the CPU "online" and "offline". This is how things used to
work in the Linux kernel at least: a CPU can be turned down but still be
present on the socket. To do that, CPU hotplug is not involved. CPU
hotplug would get involved when the user yanks the physical CPU out of
the socket.

>From what you describe, it is not the case in Xen, and it really looks
like we need support for CPU hotplug in NULL even to support for the
most basic CPU offlining/onlining functionalities.

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v6 11/13] xen: support the Null scheduler
  2018-07-02 22:08                     ` Stefano Stabellini
@ 2018-07-03 11:10                       ` Julien Grall
  2018-07-03 19:08                         ` Stefano Stabellini
  0 siblings, 1 reply; 29+ messages in thread
From: Julien Grall @ 2018-07-03 11:10 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: Artem Mygaiev, Lars Kurth, nd, andrii_anisov, George Dunlap,
	Andrew Cooper, Ian Jackson, xen-devel, Jan Beulich,
	Dario Faggioli, Roger Pau Monné

Hi Stefano,

On 02/07/18 23:08, Stefano Stabellini wrote:
> On Mon, 2 Jul 2018, Julien Grall wrote:
>> Hi,
>>
>> On 02/07/2018 19:24, Stefano Stabellini wrote:
>>> On Mon, 2 Jul 2018, Julien Grall wrote:
>>>> Hi Stefano,
>>>>
>>>> On 06/29/2018 07:38 PM, Stefano Stabellini wrote:
>>>>> On Thu, 28 Jun 2018, Roger Pau Monné wrote:
>>>>>> On Thu, Jun 28, 2018 at 09:27:08AM +0200, Dario Faggioli wrote:
>>>>>>> On Thu, 2018-06-14 at 13:20 -0700, Stefano Stabellini wrote:
>>>>>>>> On Thu, 14 Jun 2018, Andrew Cooper wrote:
>>>>>>>>> On 14/06/18 14:40, Jan Beulich wrote:
>>>>>>>>> I don't think its reasonable to alter the support status with
>>>>>>>>> this
>>>>>>>> issue
>>>>>>>>> outstanding.
>>>>>>>>
>>>>>>>> I completely missed this report, probably because I haven't paid
>>>>>>>> attention to PV-shim. Do you have any more information about this?
>>>>>>>> The
>>>>>>>> report is a bit vague. If I can't repro it, I can't fix it.
>>>>>>>>
>>>>>>>> Couldn't it be that is normal because after a while you ran out of
>>>>>>>> pcpus?
>>>>>>>>
>>>>>>>> Dario, do you have any opinion on this?
>>>>>>>>
>>>>>>> The issue that I know of is that the null scheduler does not
>>>>>>> properly
>>>>>>> support CPU hotplug/hotunplug.
>>>>>>>
>>>>>>> This is an issue on, let's say, baremetal, if you use null, and try
>>>>>>> to
>>>>>>> do CPU hotplug/hotunplug. When trying to use null as the scheduler
>>>>>>> of
>>>>>>> the shim, we run into that same issue, even if not specifically
>>>>>>> doing
>>>>>>> CPU hotplug/hotunplug (because the shim use the same path for CPU
>>>>>>> bringup, IIRC).
>>>>>>
>>>>>> The shim uses CPU hotplug/unplug when the guest brings up/down a
>>>>>> vCPU using the VCPUOP_{up/down} hypercall.
>>>>>>
>>>>>> The best description of the issue I could find is:
>>>>>>
>>>>>> https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg01085.html
>>>>>
>>>>> OK, thanks for the explanation. We don't support CPU hotplug on ARM, so
>>>>> we could mark the NULL scheduler as supported on the ARM architecture
>>>>> today? Once you implement CPU hotplug support in NULL, we could mark it
>>>>> as supported on x86 too.
>>>> Well, Mirela paved the way to support CPU hotplug (should be merged soon).
>>>> She
>>>> is looking at suspend/resume which is IHMO an extension of hotplug case.
>>>> So
>>>> are you sure this could never happen on Arm?
>>>
>>> I thought that suspend/resume didn't actually require the same kind of
>>> scheduler support that CPU hotplug needs. If suspend/resume ends up
>>> not working with scheduler NULL, then that is a problem.
>>
>> The suspend/resume code will offline the CPU one by one using cpu_down. This
>> is the same path as hotplug. So you will end up with more vCPUs than online
>> pCPUs, although the domain will be frozen. How this is going to fit in the
>> NULL scheduler?
> 
> [...]
> 
>> Virtually every platform support CPU hotplug. It is not just about "physically
>> pluggable CPUs" but any CPU that can be offline at any time.
> 
> CPU hotplug in Xen clearly doesn't work as I expected: I assumed that
> CPU hotplug would make a CPU "present" or "absent", while cpu_up/down
> would make the CPU "online" and "offline". This is how things used to
> work in the Linux kernel at least: a CPU can be turned down but still be
> present on the socket. To do that, CPU hotplug is not involved. CPU
> hotplug would get involved when the user yanks the physical CPU out of
> the socket.

Are you sure? Looking at Linux they are using the CPU hotplug subsystem 
to online/offline CPUs. This is even used to bring up secondary CPUs 
during boot. This is not very different from how Xen is behaving.

> 
>  From what you describe, it is not the case in Xen, and it really looks
> like we need support for CPU hotplug in NULL even to support for the
> most basic CPU offlining/onlining functionalities.

I think we at least want to have the bug reported by Andrew & Roger 
fixed. I am not entirely whether there would be other bug in the scheduler.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [PATCH v6 11/13] xen: support the Null scheduler
  2018-07-03 11:10                       ` Julien Grall
@ 2018-07-03 19:08                         ` Stefano Stabellini
  0 siblings, 0 replies; 29+ messages in thread
From: Stefano Stabellini @ 2018-07-03 19:08 UTC (permalink / raw)
  To: Julien Grall
  Cc: Artem Mygaiev, Lars Kurth, nd, Stefano Stabellini, andrii_anisov,
	George Dunlap, Andrew Cooper, Ian Jackson, xen-devel,
	Jan Beulich, Dario Faggioli, Roger Pau Monné

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5530 bytes --]

On Tue, 3 Jul 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 02/07/18 23:08, Stefano Stabellini wrote:
> > On Mon, 2 Jul 2018, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 02/07/2018 19:24, Stefano Stabellini wrote:
> > > > On Mon, 2 Jul 2018, Julien Grall wrote:
> > > > > Hi Stefano,
> > > > > 
> > > > > On 06/29/2018 07:38 PM, Stefano Stabellini wrote:
> > > > > > On Thu, 28 Jun 2018, Roger Pau Monné wrote:
> > > > > > > On Thu, Jun 28, 2018 at 09:27:08AM +0200, Dario Faggioli wrote:
> > > > > > > > On Thu, 2018-06-14 at 13:20 -0700, Stefano Stabellini wrote:
> > > > > > > > > On Thu, 14 Jun 2018, Andrew Cooper wrote:
> > > > > > > > > > On 14/06/18 14:40, Jan Beulich wrote:
> > > > > > > > > > I don't think its reasonable to alter the support status
> > > > > > > > > > with
> > > > > > > > > > this
> > > > > > > > > issue
> > > > > > > > > > outstanding.
> > > > > > > > > 
> > > > > > > > > I completely missed this report, probably because I haven't
> > > > > > > > > paid
> > > > > > > > > attention to PV-shim. Do you have any more information about
> > > > > > > > > this?
> > > > > > > > > The
> > > > > > > > > report is a bit vague. If I can't repro it, I can't fix it.
> > > > > > > > > 
> > > > > > > > > Couldn't it be that is normal because after a while you ran
> > > > > > > > > out of
> > > > > > > > > pcpus?
> > > > > > > > > 
> > > > > > > > > Dario, do you have any opinion on this?
> > > > > > > > > 
> > > > > > > > The issue that I know of is that the null scheduler does not
> > > > > > > > properly
> > > > > > > > support CPU hotplug/hotunplug.
> > > > > > > > 
> > > > > > > > This is an issue on, let's say, baremetal, if you use null, and
> > > > > > > > try
> > > > > > > > to
> > > > > > > > do CPU hotplug/hotunplug. When trying to use null as the
> > > > > > > > scheduler
> > > > > > > > of
> > > > > > > > the shim, we run into that same issue, even if not specifically
> > > > > > > > doing
> > > > > > > > CPU hotplug/hotunplug (because the shim use the same path for
> > > > > > > > CPU
> > > > > > > > bringup, IIRC).
> > > > > > > 
> > > > > > > The shim uses CPU hotplug/unplug when the guest brings up/down a
> > > > > > > vCPU using the VCPUOP_{up/down} hypercall.
> > > > > > > 
> > > > > > > The best description of the issue I could find is:
> > > > > > > 
> > > > > > > https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg01085.html
> > > > > > 
> > > > > > OK, thanks for the explanation. We don't support CPU hotplug on ARM,
> > > > > > so
> > > > > > we could mark the NULL scheduler as supported on the ARM
> > > > > > architecture
> > > > > > today? Once you implement CPU hotplug support in NULL, we could mark
> > > > > > it
> > > > > > as supported on x86 too.
> > > > > Well, Mirela paved the way to support CPU hotplug (should be merged
> > > > > soon).
> > > > > She
> > > > > is looking at suspend/resume which is IHMO an extension of hotplug
> > > > > case.
> > > > > So
> > > > > are you sure this could never happen on Arm?
> > > > 
> > > > I thought that suspend/resume didn't actually require the same kind of
> > > > scheduler support that CPU hotplug needs. If suspend/resume ends up
> > > > not working with scheduler NULL, then that is a problem.
> > > 
> > > The suspend/resume code will offline the CPU one by one using cpu_down.
> > > This
> > > is the same path as hotplug. So you will end up with more vCPUs than
> > > online
> > > pCPUs, although the domain will be frozen. How this is going to fit in the
> > > NULL scheduler?
> > 
> > [...]
> > 
> > > Virtually every platform support CPU hotplug. It is not just about
> > > "physically
> > > pluggable CPUs" but any CPU that can be offline at any time.
> > 
> > CPU hotplug in Xen clearly doesn't work as I expected: I assumed that
> > CPU hotplug would make a CPU "present" or "absent", while cpu_up/down
> > would make the CPU "online" and "offline". This is how things used to
> > work in the Linux kernel at least: a CPU can be turned down but still be
> > present on the socket. To do that, CPU hotplug is not involved. CPU
> > hotplug would get involved when the user yanks the physical CPU out of
> > the socket.
> 
> Are you sure? Looking at Linux they are using the CPU hotplug subsystem to
> online/offline CPUs. This is even used to bring up secondary CPUs during boot.
> This is not very different from how Xen is behaving.

arch_register/unregister_cpu in Linux make a cpu "present" and "absent"
respectively. They require CONFIG_HOTPLUG_CPU. cpu_up and cpu_down are
different operations to turn it "on" and "off" and are triggered via
sysfs. arch_register/unregister_cpu are triggered by ACPI events on
x86.

arch_register/unregister_cpu are hotplug operations, and cpu_up is not,
as expected. But it gets confusing because cpu_down depends on
CONFIG_HOTPLUG_CPU. So bringing up CPUs is not hotplug, but turning them
off at runtime is hotplug? Even though turning them off has nothing to
do with any physical or virtual "plugging". I find it very confusing. I
hope that in Xen will manage to do something clearer than this.


> >  From what you describe, it is not the case in Xen, and it really looks
> > like we need support for CPU hotplug in NULL even to support for the
> > most basic CPU offlining/onlining functionalities.
> 
> I think we at least want to have the bug reported by Andrew & Roger fixed. I
> am not entirely whether there would be other bug in the scheduler.

Sure. For the kconfig series I'll use credit instead until the issue is
fixed.

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2018-07-03 19:08 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-13 21:14 [PATCH v6 0/13] arm: more kconfig configurability and small default configs Stefano Stabellini
2018-06-13 21:14 ` [PATCH v6 01/13] arm: remove the ARM HDLCD driver Stefano Stabellini
2018-06-13 21:14 ` [PATCH v6 02/13] arm: make it possible to disable HAS_GICV3 Stefano Stabellini
2018-06-13 21:14 ` [PATCH v6 03/13] arm: rename HAS_GICV3 to GICV3 Stefano Stabellini
2018-06-13 21:14 ` [PATCH v6 04/13] Make MEM_ACCESS configurable Stefano Stabellini
2018-06-22  1:51   ` Julien Grall
2018-06-13 21:14 ` [PATCH v6 05/13] make it possible to enable/disable UART drivers Stefano Stabellini
2018-06-13 21:14 ` [PATCH v6 06/13] arm: make it possible to disable the SMMU driver Stefano Stabellini
2018-06-13 21:14 ` [PATCH v6 07/13] arm: add a tiny kconfig configuration Stefano Stabellini
2018-06-13 21:14 ` [PATCH v6 08/13] arm: add ALL, QEMU, Rcar3 and MPSoC configs Stefano Stabellini
2018-06-13 21:14 ` [PATCH v6 09/13] xen: add per-platform defaults for NR_CPUS Stefano Stabellini
2018-06-13 21:14 ` [PATCH v6 10/13] xen: add cloc target Stefano Stabellini
2018-06-13 21:14 ` [PATCH v6 11/13] xen: support the Null scheduler Stefano Stabellini
2018-06-14 13:40   ` Jan Beulich
2018-06-14 13:43     ` Andrew Cooper
2018-06-14 20:20       ` Stefano Stabellini
2018-06-28  7:27         ` Dario Faggioli
2018-06-28  7:36           ` Roger Pau Monné
2018-06-29 18:38             ` Stefano Stabellini
2018-07-02 11:31               ` Julien Grall
2018-07-02 18:24                 ` Stefano Stabellini
2018-07-02 21:07                   ` Julien Grall
2018-07-02 22:08                     ` Stefano Stabellini
2018-07-03 11:10                       ` Julien Grall
2018-07-03 19:08                         ` Stefano Stabellini
2018-06-13 21:14 ` [PATCH v6 12/13] xen: specify support for EXPERT and DEBUG Kconfig options Stefano Stabellini
2018-06-14 13:44   ` Jan Beulich
2018-06-14 20:22     ` Stefano Stabellini
2018-06-13 21:14 ` [PATCH v6 13/13] xen: clarify the security-support status of Kconfig options on ARM Stefano Stabellini

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.