[PATCH v2 0/10] arm: more kconfig configurability and small default configs

[PATCH v2 0/10] arm: more kconfig configurability and small default configs

[Stefano Stabellini]

Hi all,

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

First, the series makes a few changes to allow disabling more kconfig
options: most of them already exist but cannot be disabled.

Then, it introduces a reference kconfig for Renesas RCar (due to popular
demand, candidate for certifications) and for QEMU aarch64 (not for
certifications, but useful for debugging).

The last patch in the series adds a convenient cloc target to count the
total lines of code of the source files built.

As a consequence of these changes, some options will become user-visible
and not dependent on CONFIG_EXPERT. It does not mean that Xen Project
will security support all possible combinations of kconfig options.
Instead, there will be a small set of pre-canned configurations that
will be supported.  See: https://marc.info/?l=xen-devel&m=152424389512432

One note about Kconfig renaming: I can see the benefit of being
consistent with the naming and using HAS_ only for options that are
always enabled, but I really don't have a strong opinion on this topic.

Cheers,

Stefano


Stefano Stabellini (10):
      arm: remove the ARM HDLCD driver
      arm: make it possible to disable more kconfig options
      Rename HAS_MEM_ACCESS to MEM_ACCESS
      arm: rename HAS_GICV3 to GICV3
      arm: make it possible to enable/disable UART drivers
      xen: remove HAS_ prefix from UART Kconfig options
      arm: make it possible to disable the SMMU driver
      arm: add a small kconfig for Renesas RCar H3
      arm: add a small kconfig for qemu-system-aarch64
      xen: add cloc target

 tools/firmware/xen-dir/shim.config   |   4 +-
 xen/Makefile                         |  11 ++
 xen/arch/arm/Kconfig                 |  20 ++-
 xen/arch/arm/Makefile                |   4 +-
 xen/arch/arm/configs/qemu.config     |  53 +++++++
 xen/arch/arm/configs/rcar3.config    |  45 ++++++
 xen/arch/arm/vgic.c                  |   2 +-
 xen/arch/arm/vgic/vgic.c             |   2 +-
 xen/arch/x86/Kconfig                 |   6 +-
 xen/common/Kconfig                   |   2 +-
 xen/common/Makefile                  |   2 +-
 xen/common/domctl.c                  |   2 +-
 xen/drivers/char/Kconfig             |  33 ++--
 xen/drivers/char/Makefile            |  16 +-
 xen/drivers/passthrough/Kconfig      |   8 +
 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/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 +-
 26 files changed, 181 insertions(+), 340 deletions(-)
 create mode 100644 xen/arch/arm/configs/qemu.config
 create mode 100644 xen/arch/arm/configs/rcar3.config
 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

[PATCH v2 01/10] arm: remove the ARM HDLCD driver

[Stefano Stabellini]

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.

Suggested-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes in v2:
- patch added
---
 xen/arch/arm/Kconfig          |   1 -
 xen/drivers/video/Kconfig     |   3 -
 xen/drivers/video/Makefile    |   1 -
 xen/drivers/video/arm_hdlcd.c | 281 ------------------------------------------
 4 files changed, 286 deletions(-)
 delete mode 100644 xen/drivers/video/arm_hdlcd.c

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 8174c0c..cbd9f1b 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -17,7 +17,6 @@ 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
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:
- */
-- 
1.9.1


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

Re: [PATCH v2 01/10] arm: remove the ARM HDLCD driver

[Julien Grall]

Hi Stefano,

On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> 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.
> 
> Suggested-by: Julien Grall <julien.grall@arm.com>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> Changes in v2:
> - patch added
> ---
>   xen/arch/arm/Kconfig          |   1 -
>   xen/drivers/video/Kconfig     |   3 -
>   xen/drivers/video/Makefile    |   1 -
>   xen/drivers/video/arm_hdlcd.c | 281 ------------------------------------------
>   4 files changed, 286 deletions(-)
>   delete mode 100644 xen/drivers/video/arm_hdlcd.c
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 8174c0c..cbd9f1b 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -17,7 +17,6 @@ config ARM_64
>   config ARM
>   	def_bool y
>   	select HAS_ALTERNATIVE
> -	select HAS_ARM_HDLCD

As you drop this, you might also want to remove "select VIDEO" below

You probably want to remove "select VIDEO" below and remove 
vexpress_syscfg that only exists for vexpress.

Cheers,

-- 
Julien Grall

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

Re: [PATCH v2 01/10] arm: remove the ARM HDLCD driver

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > 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.
> > 
> > Suggested-by: Julien Grall <julien.grall@arm.com>
> > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> > ---
> > Changes in v2:
> > - patch added
> > ---
> >   xen/arch/arm/Kconfig          |   1 -
> >   xen/drivers/video/Kconfig     |   3 -
> >   xen/drivers/video/Makefile    |   1 -
> >   xen/drivers/video/arm_hdlcd.c | 281
> > ------------------------------------------
> >   4 files changed, 286 deletions(-)
> >   delete mode 100644 xen/drivers/video/arm_hdlcd.c
> > 
> > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > index 8174c0c..cbd9f1b 100644
> > --- a/xen/arch/arm/Kconfig
> > +++ b/xen/arch/arm/Kconfig
> > @@ -17,7 +17,6 @@ config ARM_64
> >   config ARM
> >   	def_bool y
> >   	select HAS_ALTERNATIVE
> > -	select HAS_ARM_HDLCD
> 
> As you drop this, you might also want to remove "select VIDEO" below
> 
> You probably want to remove "select VIDEO" below and remove vexpress_syscfg
> that only exists for vexpress.

Good suggestions, I'll make the changes

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

[PATCH v2 02/10] arm: make it possible to disable more kconfig options

[Stefano Stabellini]

Make it possible to disable the following existing kconfig options:
  HAS_GICV3
  HAS_MEM_ACCESS

Today they are silent option. This patch adds one line descriptions and
make them de/selectable.

Also, do not select VIDEO.

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

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

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index cbd9f1b..0b22cfa 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -12,16 +12,13 @@ config ARM_32
 config ARM_64
 	def_bool y
 	depends on 64BIT
-	select HAS_GICV3
 
 config ARM
 	def_bool y
 	select HAS_ALTERNATIVE
 	select HAS_DEVICE_TREE
-	select HAS_MEM_ACCESS
 	select HAS_PASSTHROUGH
 	select HAS_PDX
-	select VIDEO
 
 config ARCH_DEFCONFIG
 	string
@@ -43,6 +40,18 @@ config ACPI
 
 config HAS_GICV3
 	bool
+	prompt "GICv3 driver"
+	depends on ARM_64
+	default y
+
+config HAS_MEM_ACCESS
+	bool
+	prompt "Memory Access and VM events"
+	default y
+	---help---
+
+	  Framework to configure memory access types for guests and receive
+	  related events in userspace.
 
 config HAS_ITS
         bool
-- 
1.9.1


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

Re: [PATCH v2 02/10] arm: make it possible to disable more kconfig options

[Julien Grall]

Hi,

On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> Make it possible to disable the following existing kconfig options:
>    HAS_GICV3
>    HAS_MEM_ACCESS
> 
> Today they are silent option. This patch adds one line descriptions and
> make them de/selectable.
> 
> Also, do not select VIDEO.

IHMO, this belongs to patch #1.

> 
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> 
> ---
> Changes in v2:
> - make HAS_GICv3 depend on ARM_64
> - remove modifications to ARM_HDLCD kconfig, it has been removed
> ---
>   xen/arch/arm/Kconfig | 15 ++++++++++++---
>   1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index cbd9f1b..0b22cfa 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -12,16 +12,13 @@ config ARM_32
>   config ARM_64
>   	def_bool y
>   	depends on 64BIT
> -	select HAS_GICV3
>   
>   config ARM
>   	def_bool y
>   	select HAS_ALTERNATIVE
>   	select HAS_DEVICE_TREE
> -	select HAS_MEM_ACCESS
>   	select HAS_PASSTHROUGH
>   	select HAS_PDX
> -	select VIDEO
>   
>   config ARCH_DEFCONFIG
>   	string
> @@ -43,6 +40,18 @@ config ACPI
>   
>   config HAS_GICV3
>   	bool
> +	prompt "GICv3 driver"
> +	depends on ARM_64
> +	default y
> +
> +config HAS_MEM_ACCESS
> +	bool
> +	prompt "Memory Access and VM events"
> +	default y
> +	---help---
> +
> +	  Framework to configure memory access types for guests and receive
> +	  related events in userspace.

See my reply on v1 of this patch.

Cheers,

-- 
Julien Grall

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

Re: [PATCH v2 02/10] arm: make it possible to disable more kconfig options

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> Hi,
> 
> On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > Make it possible to disable the following existing kconfig options:
> >    HAS_GICV3
> >    HAS_MEM_ACCESS
> > 
> > Today they are silent option. This patch adds one line descriptions and
> > make them de/selectable.
> > 
> > Also, do not select VIDEO.
> 
> IHMO, this belongs to patch #1.

You are right, I made the change.

> > 
> > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> > 
> > ---
> > Changes in v2:
> > - make HAS_GICv3 depend on ARM_64
> > - remove modifications to ARM_HDLCD kconfig, it has been removed
> > ---
> >   xen/arch/arm/Kconfig | 15 ++++++++++++---
> >   1 file changed, 12 insertions(+), 3 deletions(-)
> > 
> > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > index cbd9f1b..0b22cfa 100644
> > --- a/xen/arch/arm/Kconfig
> > +++ b/xen/arch/arm/Kconfig
> > @@ -12,16 +12,13 @@ config ARM_32
> >   config ARM_64
> >   	def_bool y
> >   	depends on 64BIT
> > -	select HAS_GICV3
> >     config ARM
> >   	def_bool y
> >   	select HAS_ALTERNATIVE
> >   	select HAS_DEVICE_TREE
> > -	select HAS_MEM_ACCESS
> >   	select HAS_PASSTHROUGH
> >   	select HAS_PDX
> > -	select VIDEO
> >     config ARCH_DEFCONFIG
> >   	string
> > @@ -43,6 +40,18 @@ config ACPI
> >     config HAS_GICV3
> >   	bool
> > +	prompt "GICv3 driver"
> > +	depends on ARM_64
> > +	default y
> > +
> > +config HAS_MEM_ACCESS
> > +	bool
> > +	prompt "Memory Access and VM events"
> > +	default y
> > +	---help---
> > +
> > +	  Framework to configure memory access types for guests and receive
> > +	  related events in userspace.
> 
> See my reply on v1 of this patch.

I replied there. I would prefer to keep it. At least, I would like to do
the renaming of HAS_MEM_ACCESS to MEM_ACCESS as part of this series to
make my work easier.

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

Re: [PATCH v2 02/10] arm: make it possible to disable more kconfig options

[Julien Grall]

On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> Make it possible to disable the following existing kconfig options:
>    HAS_GICV3
>    HAS_MEM_ACCESS
> 
> Today they are silent option. This patch adds one line descriptions and
> make them de/selectable.
> 
> Also, do not select VIDEO.
> 
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> 
> ---
> Changes in v2:
> - make HAS_GICv3 depend on ARM_64
> - remove modifications to ARM_HDLCD kconfig, it has been removed
> ---
>   xen/arch/arm/Kconfig | 15 ++++++++++++---
>   1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index cbd9f1b..0b22cfa 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -12,16 +12,13 @@ config ARM_32
>   config ARM_64
>   	def_bool y
>   	depends on 64BIT
> -	select HAS_GICV3
>   
>   config ARM
>   	def_bool y
>   	select HAS_ALTERNATIVE
>   	select HAS_DEVICE_TREE
> -	select HAS_MEM_ACCESS
>   	select HAS_PASSTHROUGH
>   	select HAS_PDX
> -	select VIDEO
>   
>   config ARCH_DEFCONFIG
>   	string
> @@ -43,6 +40,18 @@ config ACPI
>   
>   config HAS_GICV3
>   	bool
> +	prompt "GICv3 driver"
> +	depends on ARM_64
> +	default y

All the new options should have a description.

> +
> +config HAS_MEM_ACCESS
> +	bool
> +	prompt "Memory Access and VM events"
> +	default y
> +	---help---
> +
> +	  Framework to configure memory access types for guests and receive
> +	  related events in userspace.
>   
>   config HAS_ITS
>           bool
> 

-- 
Julien Grall

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

Re: [PATCH v2 02/10] arm: make it possible to disable more kconfig options

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > Make it possible to disable the following existing kconfig options:
> >    HAS_GICV3
> >    HAS_MEM_ACCESS
> > 
> > Today they are silent option. This patch adds one line descriptions and
> > make them de/selectable.
> > 
> > Also, do not select VIDEO.
> > 
> > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> > 
> > ---
> > Changes in v2:
> > - make HAS_GICv3 depend on ARM_64
> > - remove modifications to ARM_HDLCD kconfig, it has been removed
> > ---
> >   xen/arch/arm/Kconfig | 15 ++++++++++++---
> >   1 file changed, 12 insertions(+), 3 deletions(-)
> > 
> > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > index cbd9f1b..0b22cfa 100644
> > --- a/xen/arch/arm/Kconfig
> > +++ b/xen/arch/arm/Kconfig
> > @@ -12,16 +12,13 @@ config ARM_32
> >   config ARM_64
> >   	def_bool y
> >   	depends on 64BIT
> > -	select HAS_GICV3
> >     config ARM
> >   	def_bool y
> >   	select HAS_ALTERNATIVE
> >   	select HAS_DEVICE_TREE
> > -	select HAS_MEM_ACCESS
> >   	select HAS_PASSTHROUGH
> >   	select HAS_PDX
> > -	select VIDEO
> >     config ARCH_DEFCONFIG
> >   	string
> > @@ -43,6 +40,18 @@ config ACPI
> >     config HAS_GICV3
> >   	bool
> > +	prompt "GICv3 driver"
> > +	depends on ARM_64
> > +	default y
> 
> All the new options should have a description.

Yes, I'll add a description


> > +
> > +config HAS_MEM_ACCESS
> > +	bool
> > +	prompt "Memory Access and VM events"
> > +	default y
> > +	---help---
> > +
> > +	  Framework to configure memory access types for guests and receive
> > +	  related events in userspace.
> >     config HAS_ITS
> >           bool
> > 
> 
> -- 
> Julien Grall
> 

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

[PATCH v2 03/10] Rename HAS_MEM_ACCESS to MEM_ACCESS

[Stefano Stabellini]

HAS_MEM_ACCESS has become selectable by the user on ARM32 and ARM64. To
mark the change, rename the option from HAS_MEM_ACCESS to MEM_ACCESS.

Suggested-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
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

---
Actually, I don't have an opinion on KConfig names. I am happy to keep
as this or rename to something else.

Changes in v2:
- patch added
---
 tools/firmware/xen-dir/shim.config | 2 +-
 xen/arch/arm/Kconfig               | 2 +-
 xen/arch/x86/Kconfig               | 2 +-
 xen/common/Kconfig                 | 2 +-
 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, 14 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 0b22cfa..14d2be5 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -44,7 +44,7 @@ config HAS_GICV3
 	depends on ARM_64
 	default y
 
-config HAS_MEM_ACCESS
+config MEM_ACCESS
 	bool
 	prompt "Memory Access and VM events"
 	default y
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index f64fc56..34d7c4b 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
 	select HAS_MEM_PAGING
 	select HAS_MEM_SHARING
 	select HAS_NS16550
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 9043dce..9020682 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -20,7 +20,7 @@ config HAS_DEVICE_TREE
 config HAS_EX_TABLE
 	bool
 
-config HAS_MEM_ACCESS
+config MEM_ACCESS
 	bool
 
 config HAS_MEM_PAGING
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

Re: [PATCH v2 03/10] Rename HAS_MEM_ACCESS to MEM_ACCESS

[Jan Beulich]

>>> Stefano Stabellini <sstabellini@kernel.org> 05/22/18 2:53 AM >>>
>HAS_MEM_ACCESS has become selectable by the user on ARM32 and ARM64. To
>mark the change, rename the option from HAS_MEM_ACCESS to MEM_ACCESS.

I have a different suggestion, a model used (iirc) in a couple of places in Linux:
The feature controlling option is, as you make it here, MEM_ACCESS. It should
live in a non-arch-specific Kconfig though, and should be controlled by two further
options: HAS_MEM_ACCESS (telling whether the arch actually is capable of
doing this, i.e. MEM_ACCESS to depend on it) and something like
MEM_ACCESS_ALWAYS_ON (telling whether the prompt should be hidden and,
if the default with prompt enabled was "no", also controlling the default).

Jan



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

Re: [PATCH v2 03/10] Rename HAS_MEM_ACCESS to MEM_ACCESS

[Stefano Stabellini]

On Tue, 22 May 2018, Jan Beulich wrote:
> >>> Stefano Stabellini <sstabellini@kernel.org> 05/22/18 2:53 AM >>>
> >HAS_MEM_ACCESS has become selectable by the user on ARM32 and ARM64. To
> >mark the change, rename the option from HAS_MEM_ACCESS to MEM_ACCESS.
> 
> I have a different suggestion, a model used (iirc) in a couple of places in Linux:
> The feature controlling option is, as you make it here, MEM_ACCESS. It should
> live in a non-arch-specific Kconfig though, and should be controlled by two further
> options: HAS_MEM_ACCESS (telling whether the arch actually is capable of
> doing this, i.e. MEM_ACCESS to depend on it) and something like
> MEM_ACCESS_ALWAYS_ON (telling whether the prompt should be hidden and,
> if the default with prompt enabled was "no", also controlling the default).

I like this suggestion very much, I'll do that.

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

[PATCH v2 04/10] arm: rename HAS_GICV3 to GICV3

[Stefano Stabellini]

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>

---
Actually, I don't have an opinion on KConfig names. I am happy to keep
as this or rename to something else.

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 14d2be5..8eb379c 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -38,7 +38,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
@@ -56,7 +56,7 @@ config MEM_ACCESS
 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

[PATCH v2 05/10] arm: make it possible to enable/disable UART drivers

[Stefano Stabellini]

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

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

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

diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index cc78ec3..9ffbfa7 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -1,11 +1,11 @@
 config HAS_NS16550
-	bool
+	bool "NS16550 UART driver"
 	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
@@ -53,7 +53,8 @@ config HAS_SCIF
 	  or Renesas R-Car Gen 2/3 based board say Y.
 
 config HAS_EHCI
-	bool
+	bool "EHCI UART driver"
+	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

Re: [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers

[Jan Beulich]

>>> Stefano Stabellini <sstabellini@kernel.org> 05/22/18 2:53 AM >>>
>All the UART drivers are silent options. Add one line descriptions so
>that can be de/selected via menuconfig.
>
>Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>

Please don't forget to Cc maintainers.


>--- a/xen/drivers/char/Kconfig
>+++ b/xen/drivers/char/Kconfig
>@@ -1,11 +1,11 @@
>config HAS_NS16550
>-	bool
>+	bool "NS16550 UART driver"

Here as well as ...


>@@ -53,7 +53,8 @@ config HAS_SCIF
>or Renesas R-Car Gen 2/3 based board say Y.
 >
>config HAS_EHCI
>-	bool
>+	bool "EHCI UART driver"

... here iirc Julien had already pointed out that the drivers should not become
optional on x86, i.e. in the former case you want to attach a conditional to the
prompt while in the latter case I don't see why you add the prompt in the first
place if you mean to make it x86-specific. Which by itself is questionable
though: Why would this driver be x86-specific, when so far it (consciously)
hasn't been? If anything I could see it depend on HAS_PCI.


>+	depends on x86

Is Kconfig case-insensitive? The option is X86.

Jan



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

Re: [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers

[Julien Grall]

Title: This is nothing very specific to arm.

On 05/22/2018 07:34 AM, Jan Beulich wrote:
>>>> Stefano Stabellini <sstabellini@kernel.org> 05/22/18 2:53 AM >>>
>> All the UART drivers are silent options. Add one line descriptions so
>> that can be de/selected via menuconfig.
>>
>> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> 
> Please don't forget to Cc maintainers.
> 
> 
>> --- a/xen/drivers/char/Kconfig
>> +++ b/xen/drivers/char/Kconfig
>> @@ -1,11 +1,11 @@
>> config HAS_NS16550
>> -	bool
>> +	bool "NS16550 UART driver"
> 
> Here as well as ...
> 
> 
>> @@ -53,7 +53,8 @@ config HAS_SCIF
>> or Renesas R-Car Gen 2/3 based board say Y.
>   >
>> config HAS_EHCI
>> -	bool
>> +	bool "EHCI UART driver"
> 
> ... here iirc Julien had already pointed out that the drivers should not become
> optional on x86, i.e. in the former case you want to attach a conditional to the
> prompt while in the latter case I don't see why you add the prompt in the first
> place if you mean to make it x86-specific. Which by itself is questionable
> though: Why would this driver be x86-specific, when so far it (consciously)
> hasn't been? If anything I could see it depend on HAS_PCI.

I don't expect this piece of hardware to come up on Arm. Furthermore 
HAS_PCI will get selected at some point by Arm. But we need to avoid 
selecting that driver. The solution I can see here is keeping the 
architecture selecting the option as it is done today.

Cheers,

-- 
Julien Grall

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

Re: [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers

[Jan Beulich]

>>> On 22.05.18 at 10:51, <julien.grall@arm.com> wrote:
> On 05/22/2018 07:34 AM, Jan Beulich wrote:
>>>>> Stefano Stabellini <sstabellini@kernel.org> 05/22/18 2:53 AM >>>
>>> @@ -53,7 +53,8 @@ config HAS_SCIF
>>> or Renesas R-Car Gen 2/3 based board say Y.
>>   >
>>> config HAS_EHCI
>>> -	bool
>>> +	bool "EHCI UART driver"
>> 
>> ... here iirc Julien had already pointed out that the drivers should not become
>> optional on x86, i.e. in the former case you want to attach a conditional to the
>> prompt while in the latter case I don't see why you add the prompt in the first
>> place if you mean to make it x86-specific. Which by itself is questionable
>> though: Why would this driver be x86-specific, when so far it (consciously)
>> hasn't been? If anything I could see it depend on HAS_PCI.
> 
> I don't expect this piece of hardware to come up on Arm.

I can read two meanings into this: You expect the driver to not work on
ARM, or you're confident the EHCI protocol of accessing USB host
controller hardware not used anywhere in devices used on ARM. Which
of the two you mean determines what the correct approach here is.

Jan



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

Re: [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers

[Julien Grall]

Hi Jan,

On 05/22/2018 10:22 AM, Jan Beulich wrote:
>>>> On 22.05.18 at 10:51, <julien.grall@arm.com> wrote:
>> On 05/22/2018 07:34 AM, Jan Beulich wrote:
>>>>>> Stefano Stabellini <sstabellini@kernel.org> 05/22/18 2:53 AM >>>
>>>> @@ -53,7 +53,8 @@ config HAS_SCIF
>>>> or Renesas R-Car Gen 2/3 based board say Y.
>>>    >
>>>> config HAS_EHCI
>>>> -	bool
>>>> +	bool "EHCI UART driver"
>>>
>>> ... here iirc Julien had already pointed out that the drivers should not become
>>> optional on x86, i.e. in the former case you want to attach a conditional to the
>>> prompt while in the latter case I don't see why you add the prompt in the first
>>> place if you mean to make it x86-specific. Which by itself is questionable
>>> though: Why would this driver be x86-specific, when so far it (consciously)
>>> hasn't been? If anything I could see it depend on HAS_PCI.
>>
>> I don't expect this piece of hardware to come up on Arm.
> 
> I can read two meanings into this: You expect the driver to not work on
> ARM, or you're confident the EHCI protocol of accessing USB host
> controller hardware not used anywhere in devices used on ARM. Which
> of the two you mean determines what the correct approach here is.

I am quite confident the EHCI protocol is not used on Arm.

Cheers,

-- 
Julien Grall

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

Re: [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers

[Jan Beulich]

>>> On 22.05.18 at 11:25, <julien.grall@arm.com> wrote:
> On 05/22/2018 10:22 AM, Jan Beulich wrote:
>>>>> On 22.05.18 at 10:51, <julien.grall@arm.com> wrote:
>>> On 05/22/2018 07:34 AM, Jan Beulich wrote:
>>>>>>> Stefano Stabellini <sstabellini@kernel.org> 05/22/18 2:53 AM >>>
>>>>> @@ -53,7 +53,8 @@ config HAS_SCIF
>>>>> or Renesas R-Car Gen 2/3 based board say Y.
>>>>    >
>>>>> config HAS_EHCI
>>>>> -	bool
>>>>> +	bool "EHCI UART driver"
>>>>
>>>> ... here iirc Julien had already pointed out that the drivers should not become
>>>> optional on x86, i.e. in the former case you want to attach a conditional to the
>>>> prompt while in the latter case I don't see why you add the prompt in the first
>>>> place if you mean to make it x86-specific. Which by itself is questionable
>>>> though: Why would this driver be x86-specific, when so far it (consciously)
>>>> hasn't been? If anything I could see it depend on HAS_PCI.
>>>
>>> I don't expect this piece of hardware to come up on Arm.
>> 
>> I can read two meanings into this: You expect the driver to not work on
>> ARM, or you're confident the EHCI protocol of accessing USB host
>> controller hardware not used anywhere in devices used on ARM. Which
>> of the two you mean determines what the correct approach here is.
> 
> I am quite confident the EHCI protocol is not used on Arm.

And why would that be? I thought PCI was universal enough that I could
put basically any card into a system independent of CPU architecture,
perhaps with the exception of such requiring option ROMs but not offering
an EFI Byte Code flavor of that code.

Jan



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

Re: [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers

[Julien Grall]

On 22/05/18 10:37, Jan Beulich wrote:
>>>> On 22.05.18 at 11:25, <julien.grall@arm.com> wrote:
>> On 05/22/2018 10:22 AM, Jan Beulich wrote:
>>>>>> On 22.05.18 at 10:51, <julien.grall@arm.com> wrote:
>>>> On 05/22/2018 07:34 AM, Jan Beulich wrote:
>>>>>>>> Stefano Stabellini <sstabellini@kernel.org> 05/22/18 2:53 AM >>>
>>>>>> @@ -53,7 +53,8 @@ config HAS_SCIF
>>>>>> or Renesas R-Car Gen 2/3 based board say Y.
>>>>>     >
>>>>>> config HAS_EHCI
>>>>>> -	bool
>>>>>> +	bool "EHCI UART driver"
>>>>>
>>>>> ... here iirc Julien had already pointed out that the drivers should not become
>>>>> optional on x86, i.e. in the former case you want to attach a conditional to the
>>>>> prompt while in the latter case I don't see why you add the prompt in the first
>>>>> place if you mean to make it x86-specific. Which by itself is questionable
>>>>> though: Why would this driver be x86-specific, when so far it (consciously)
>>>>> hasn't been? If anything I could see it depend on HAS_PCI.
>>>>
>>>> I don't expect this piece of hardware to come up on Arm.
>>>
>>> I can read two meanings into this: You expect the driver to not work on
>>> ARM, or you're confident the EHCI protocol of accessing USB host
>>> controller hardware not used anywhere in devices used on ARM. Which
>>> of the two you mean determines what the correct approach here is.
>>
>> I am quite confident the EHCI protocol is not used on Arm.
> 
> And why would that be? I thought PCI was universal enough that I could
> put basically any card into a system independent of CPU architecture,
> perhaps with the exception of such requiring option ROMs but not offering
> an EFI Byte Code flavor of that code.

Well, ARM ecosystem has already plenty of UART implemented directly in 
the SoC. The most common one are ns16550 and pl011.

On server side, the SBSA (Standard Base Server Architecture) mandates 
platform to implement the Arm Generic UART (a subset of PL011).

So I see very limited reason to have an EHCI PCI card on ARM platform.

Let's imagine someone really want to use an EHCI PCI card. That driver, 
aside enabling PCI, will require some bits for Arm (such as calling the 
initial setup) and likely going to need some testing. That effort is not 
worth given that Xen will always be able to use another UART (thanks to 
our 7 different driver).

The user should use either the pl011 or ns16550 on Arm for Xen. If 
someone wants something different, then he needs to come up with an 
explanation why it is needed and the patch/testing for it.

Meanwhile, that driver should not be selectable on Arm.

Cheers,

-- 
Julien Grall

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

Re: [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers

[Stefano Stabellini]

On Tue, 22 May 2018, Jan Beulich wrote:
> >>> Stefano Stabellini <sstabellini@kernel.org> 05/22/18 2:53 AM >>>
> >All the UART drivers are silent options. Add one line descriptions so
> >that can be de/selected via menuconfig.
> >
> >Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> 
> Please don't forget to Cc maintainers.

You and Andrew will be CCed on this patch from now on


> >--- a/xen/drivers/char/Kconfig
> >+++ b/xen/drivers/char/Kconfig
> >@@ -1,11 +1,11 @@
> >config HAS_NS16550
> >-	bool
> >+	bool "NS16550 UART driver"
> 
> Here as well as ...
> 
> 
> >@@ -53,7 +53,8 @@ config HAS_SCIF
> >or Renesas R-Car Gen 2/3 based board say Y.
>  >
> >config HAS_EHCI
> >-	bool
> >+	bool "EHCI UART driver"
> 
> ... here iirc Julien had already pointed out that the drivers should not become
> optional on x86,

I see, not only they should be enabled by default, but it should NOT be
possible to disable them.

I got it, I'll fix.


> i.e. in the former case you want to attach a conditional to the
> prompt while in the latter case I don't see why you add the prompt in the first
> place if you mean to make it x86-specific. Which by itself is questionable
> though: Why would this driver be x86-specific, when so far it (consciously)
> hasn't been? If anything I could see it depend on HAS_PCI.

I'll reply here, but I have read the rest of the thread on this point. I
think we might as well disable it for now on ARM until somebody tells us
that it is useful to have.


> >+	depends on x86
> 
> Is Kconfig case-insensitive? The option is X86.

I'll fix

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

[PATCH v2 06/10] xen: remove HAS_ prefix from UART Kconfig options

[Stefano Stabellini]

UART drivers are now selectable by the user. To mark the change, remove
the HAS_ prefix.

Suggested-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
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


---
Actually, I don't have an opinion on KConfig names. I am happy to keep
as this or rename to something else.

Changes in v2:
- patch added
---
 tools/firmware/xen-dir/shim.config |  2 +-
 xen/arch/x86/Kconfig               |  4 ++--
 xen/drivers/char/Kconfig           | 16 ++++++++--------
 xen/drivers/char/Makefile          | 16 ++++++++--------
 4 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/tools/firmware/xen-dir/shim.config b/tools/firmware/xen-dir/shim.config
index 21d7075..d3a40e7 100644
--- a/tools/firmware/xen-dir/shim.config
+++ b/tools/firmware/xen-dir/shim.config
@@ -63,7 +63,7 @@ CONFIG_ACPI=y
 CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y
 CONFIG_NUMA=y
 CONFIG_HAS_NS16550=y
-CONFIG_HAS_EHCI=y
+CONFIG_EHCI=y
 CONFIG_HAS_CPUFREQ=y
 CONFIG_HAS_PASSTHROUGH=y
 CONFIG_HAS_PCI=y
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 34d7c4b..770e640 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -10,7 +10,7 @@ config X86
 	select CORE_PARKING
 	select HAS_ALTERNATIVE
 	select HAS_CPUFREQ
-	select HAS_EHCI
+	select EHCI
 	select HAS_EX_TABLE
 	select HAS_GDBSX
 	select HAS_IOPORTS
@@ -18,7 +18,7 @@ config X86
 	select MEM_ACCESS
 	select HAS_MEM_PAGING
 	select HAS_MEM_SHARING
-	select HAS_NS16550
+	select NS16550
 	select HAS_PASSTHROUGH
 	select HAS_PCI
 	select HAS_PDX
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index 9ffbfa7..ad409ff 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -1,10 +1,10 @@
-config HAS_NS16550
+config NS16550
 	bool "NS16550 UART driver"
 	default y
 	help
 	  This selects the 16550-series UART support. For most systems, say Y.
 
-config HAS_CADENCE_UART
+config CADENCE_UART
 	bool "Xilinx Cadence UART driver"
 	default y
 	depends on ARM_64
@@ -12,7 +12,7 @@ config HAS_CADENCE_UART
 	  This selects the Xilinx Zynq Cadence UART. If you have a Xilinx Zynq
 	  based board, say Y.
 
-config HAS_MVEBU
+config MVEBU
 	bool "Marvell MVEBU UART driver"
 	default y
 	depends on ARM_64
@@ -20,7 +20,7 @@ config HAS_MVEBU
 	  This selects the Marvell MVEBU UART. If you have a ARMADA 3700
 	  based board, say Y.
 
-config HAS_PL011
+config PL011
 	bool "ARM PL011 UART driver"
 	default y
 	depends on ARM
@@ -28,7 +28,7 @@ config HAS_PL011
 	  This selects the ARM(R) AMBA(R) PrimeCell PL011 UART. If you have
 	  an Integrator/PP2, Integrator/CP or Versatile platform, say Y.
 
-config HAS_EXYNOS4210
+config EXYNOS4210
 	bool "Samsung Exynos 4210 UART driver"
 	default y
 	depends on ARM_32
@@ -36,7 +36,7 @@ config HAS_EXYNOS4210
 	  This selects the Samsung Exynos 4210 UART. If you have a Samsung
 	  Exynos based board, say Y.
 
-config HAS_OMAP
+config OMAP
 	bool "Texas Instruments OMAP UART driver"
 	default y
 	depends on ARM_32
@@ -44,7 +44,7 @@ config HAS_OMAP
 	  This selects the Texas Instruments OMAP UART. If you have a Texas
 	  Instruments based CPU, say Y.
 
-config HAS_SCIF
+config SCIF
 	bool "SuperH SCI(F) UART driver"
 	default y
 	depends on ARM
@@ -52,7 +52,7 @@ config HAS_SCIF
 	  This selects the SuperH SCI(F) UART. If you have a SuperH based board,
 	  or Renesas R-Car Gen 2/3 based board say Y.
 
-config HAS_EHCI
+config EHCI
 	bool "EHCI UART driver"
 	depends on x86
 	help
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index b68c330..94014c3 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,12 +1,12 @@
 obj-y += console.o
-obj-$(CONFIG_HAS_NS16550) += ns16550.o
-obj-$(CONFIG_HAS_CADENCE_UART) += cadence-uart.o
-obj-$(CONFIG_HAS_PL011) += pl011.o
-obj-$(CONFIG_HAS_EXYNOS4210) += exynos4210-uart.o
-obj-$(CONFIG_HAS_MVEBU) += mvebu-uart.o
-obj-$(CONFIG_HAS_OMAP) += omap-uart.o
-obj-$(CONFIG_HAS_SCIF) += scif-uart.o
-obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
+obj-$(CONFIG_NS16550) += ns16550.o
+obj-$(CONFIG_CADENCE_UART) += cadence-uart.o
+obj-$(CONFIG_PL011) += pl011.o
+obj-$(CONFIG_EXYNOS4210) += exynos4210-uart.o
+obj-$(CONFIG_MVEBU) += mvebu-uart.o
+obj-$(CONFIG_OMAP) += omap-uart.o
+obj-$(CONFIG_SCIF) += scif-uart.o
+obj-$(CONFIG_EHCI) += ehci-dbgp.o
 obj-$(CONFIG_ARM) += arm-uart.o
 obj-y += serial.o
 obj-$(CONFIG_XEN_GUEST) += xen_pv_console.o
-- 
1.9.1


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

Re: [PATCH v2 06/10] xen: remove HAS_ prefix from UART Kconfig options

[Jan Beulich]

>>> Stefano Stabellini <sstabellini@kernel.org> 05/22/18 2:53 AM >>>
>UART drivers are now selectable by the user. To mark the change, remove
>the HAS_ prefix.

Same comment as on patch 3.

Jan



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

Re: [PATCH v2 06/10] xen: remove HAS_ prefix from UART Kconfig options

[Stefano Stabellini]

On Tue, 22 May 2018, Jan Beulich wrote:
> >>> Stefano Stabellini <sstabellini@kernel.org> 05/22/18 2:53 AM >>>
> >UART drivers are now selectable by the user. To mark the change, remove
> >the HAS_ prefix.
> 
> Same comment as on patch 3.

I'll do. That will also solve your comments to the previous patch in a
cleaner way.

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

[PATCH v2 07/10] arm: make it possible to disable the SMMU driver

[Stefano Stabellini]

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

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
CC: jbeulich@suse.com

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

diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig
index 8d90b67..9bdce65 100644
--- a/xen/drivers/passthrough/Kconfig
+++ b/xen/drivers/passthrough/Kconfig
@@ -1,3 +1,11 @@
 
 config HAS_PASSTHROUGH
 	bool
+
+config SMMUv2
+	bool "ARM SMMUv1 and v2 driver"
+	default y
+	depends on ARM
+	---help---
+	  Driver for the ARM SMMU version 1 and 2, a popular IOMMU by
+	  ARM.
diff --git a/xen/drivers/passthrough/arm/Makefile b/xen/drivers/passthrough/arm/Makefile
index f4cd26e..290c2cd 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-$(SMMUv2) += smmu.o
-- 
1.9.1


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

Re: [PATCH v2 07/10] arm: make it possible to disable the SMMU driver

[Jan Beulich]

>--- a/xen/drivers/passthrough/Kconfig
>+++ b/xen/drivers/passthrough/Kconfig
>@@ -1,3 +1,11 @@
 >
>config HAS_PASSTHROUGH
>bool
>+
>+config SMMUv2
>+	bool "ARM SMMUv1 and v2 driver"
>+	default y
>+	depends on ARM

Anticipating further additions here, I would prefer the "if ARM" form, but as it
doesn't really matter right now I won't insist.


>--- 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-$(SMMUv2) += smmu.o

Is iommu.o in any way useful without smmu.o?

Jan



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

Re: [PATCH v2 07/10] arm: make it possible to disable the SMMU driver

[Stefano Stabellini]

On Tue, 22 May 2018, Jan Beulich wrote:
> >--- a/xen/drivers/passthrough/Kconfig
> >+++ b/xen/drivers/passthrough/Kconfig
> >@@ -1,3 +1,11 @@
>  >
> >config HAS_PASSTHROUGH
> >bool
> >+
> >+config SMMUv2
> >+	bool "ARM SMMUv1 and v2 driver"
> >+	default y
> >+	depends on ARM
> 
> Anticipating further additions here, I would prefer the "if ARM" form, but as it
> doesn't really matter right now I won't insist.

I'll make the change

 
> >--- 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-$(SMMUv2) += smmu.o
> 
> Is iommu.o in any way useful without smmu.o?

Things like iommu_domain_init are called unconditionally from ARM code
at the moment, it is not quite possible to skip compilation today. Also,
it is small, so it is not worth it I think.

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

Re: [PATCH v2 07/10] arm: make it possible to disable the SMMU driver

[Julien Grall]

Hi,

On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver.
> 
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> CC: jbeulich@suse.com
> 
> ---
> Changes in v2:
> - rename HAS_SMMUv2 to SMMUv2
> - move SMMUv2 to xen/drivers/passthrough/Kconfig
> ---
>   xen/drivers/passthrough/Kconfig      | 8 ++++++++
>   xen/drivers/passthrough/arm/Makefile | 2 +-
>   2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig
> index 8d90b67..9bdce65 100644
> --- a/xen/drivers/passthrough/Kconfig
> +++ b/xen/drivers/passthrough/Kconfig
> @@ -1,3 +1,11 @@
>   
>   config HAS_PASSTHROUGH
>   	bool
> +
> +config SMMUv2

It would make sense to have ARM in the name because there are other 
using SMMU in their device name (see Tegra). Furthermore this is not 
only v2 specific.

A better name would be ARM_SMMU.

> +	bool "ARM SMMUv1 and v2 driver"
> +	default y
> +	depends on ARM
> +	---help---
> +	  Driver for the ARM SMMU version 1 and 2, a popular IOMMU by
> +	  ARM.

The driver enables support for any IOMMU based on the ARM System MMU 
architecture versions 1 and 2. ARM provides implementation (SMMU-400, 
SMMU-401, SMMU-500 & co) but there are other existing in the wild (e.g 
Cavium one).

Also, in general it would be useful to state why someone would want to 
enable a driver. So I would rework this message as:

"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".

Cheers,

-- 
Julien Grall

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

Re: [PATCH v2 07/10] arm: make it possible to disable the SMMU driver

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> Hi,
> 
> On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver.
> > 
> > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> > CC: jbeulich@suse.com
> > 
> > ---
> > Changes in v2:
> > - rename HAS_SMMUv2 to SMMUv2
> > - move SMMUv2 to xen/drivers/passthrough/Kconfig
> > ---
> >   xen/drivers/passthrough/Kconfig      | 8 ++++++++
> >   xen/drivers/passthrough/arm/Makefile | 2 +-
> >   2 files changed, 9 insertions(+), 1 deletion(-)
> > 
> > diff --git a/xen/drivers/passthrough/Kconfig
> > b/xen/drivers/passthrough/Kconfig
> > index 8d90b67..9bdce65 100644
> > --- a/xen/drivers/passthrough/Kconfig
> > +++ b/xen/drivers/passthrough/Kconfig
> > @@ -1,3 +1,11 @@
> >     config HAS_PASSTHROUGH
> >   	bool
> > +
> > +config SMMUv2
> 
> It would make sense to have ARM in the name because there are other using SMMU
> in their device name (see Tegra). Furthermore this is not only v2 specific.
> 
> A better name would be ARM_SMMU.
> 
> > +	bool "ARM SMMUv1 and v2 driver"
> > +	default y
> > +	depends on ARM
> > +	---help---
> > +	  Driver for the ARM SMMU version 1 and 2, a popular IOMMU by
> > +	  ARM.
> 
> The driver enables support for any IOMMU based on the ARM System MMU
> architecture versions 1 and 2. ARM provides implementation (SMMU-400,
> SMMU-401, SMMU-500 & co) but there are other existing in the wild (e.g Cavium
> one).
> 
> Also, in general it would be useful to state why someone would want to enable
> a driver. So I would rework this message as:
> 
> "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".

I'll use ARM_SMMU and use your suggestion for the help message.

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

[PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3

[Stefano Stabellini]

This is a reference tiny kconfig for Renesas RCar.  In terms of
schedulers, it selects credit and NULL only.  It enables all the ARM64
errata.

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

---

This patch is untested on Renesas RCar, please test!
Also, I am not sure whether some of the errata workarounds can be
disabled on the RCar.

Changes in v2:
- rename to rcar3
- only add required symbols, let the defauls take care of the rest
---
 xen/arch/arm/configs/rcar3.config | 45 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)
 create mode 100644 xen/arch/arm/configs/rcar3.config

diff --git a/xen/arch/arm/configs/rcar3.config b/xen/arch/arm/configs/rcar3.config
new file mode 100644
index 0000000..4fadcf9
--- /dev/null
+++ b/xen/arch/arm/configs/rcar3.config
@@ -0,0 +1,45 @@
+CONFIG_ARM_64=y
+CONFIG_ARM=y
+
+#
+# Architecture Features
+#
+CONFIG_NR_CPUS=8
+# CONFIG_ACPI is not set
+# 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_NS16550 is not set
+# CONFIG_CADENCE_UART is not set
+# CONFIG_MVEBU is not set
+# CONFIG_PL011 is not set
+CONFIG_SCIF=y
+CONFIG_SMMUv2=y
+
+#
+# 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

Re: [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3

[Julien Grall]

Hi,

On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> This is a reference tiny kconfig for Renesas RCar.  In terms of
> schedulers, it selects credit and NULL only.  It enables all the ARM64
> errata.

It still does not feel right that you select only credit and NULL. Why 
not credit2 and NULL? Or other combination.


> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> CC: artem_mygaiev@epam.com
> CC: volodymyr_babchuk@epam.com
> 
> ---
> 
> This patch is untested on Renesas RCar, please test!
> Also, I am not sure whether some of the errata workarounds can be
> disabled on the RCar.
> 
> Changes in v2:
> - rename to rcar3
> - only add required symbols, let the defauls take care of the rest

I am not sure what you mean here. Your .config below seems contains all 
the options including the non-selected one.

Also, this still not solving the problem raised by Andrew regarding keep 
them updated.

It might be easier to maintain if we provide a per platform config 
option (e.g CONFIG_RCAR3) that will select driver for that specific board.

The user is then free to select other components (e.g scheduler...). So 
you don't impose memaccess disabled, NULL scheduler...

(Thank you Andrii for the suggestion!)

> +# CONFIG_NS16550 is not set
> +# CONFIG_CADENCE_UART is not set
> +# CONFIG_MVEBU is not set
> +# CONFIG_PL011 is not set
> +CONFIG_SCIF=y
> +CONFIG_SMMUv2=y

IIRC the RCAR does not have an SMMU.

Cheers,

-- 
Julien Grall

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

Re: [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> Hi,
> 
> On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > This is a reference tiny kconfig for Renesas RCar.  In terms of
> > schedulers, it selects credit and NULL only.  It enables all the ARM64
> > errata.
> 
> It still does not feel right that you select only credit and NULL. Why not
> credit2 and NULL? Or other combination.

We have to pick a combination of options for certifications and this is
the one I am proposing: we need the null scheduler for latency sensitive
mission critical VMs and we need credit (the default today) for the
others.

I am happy to discuss the pros and cons of other combinations.

 
> > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> > CC: artem_mygaiev@epam.com
> > CC: volodymyr_babchuk@epam.com
> > 
> > ---
> > 
> > This patch is untested on Renesas RCar, please test!
> > Also, I am not sure whether some of the errata workarounds can be
> > disabled on the RCar.
> > 
> > Changes in v2:
> > - rename to rcar3
> > - only add required symbols, let the defauls take care of the rest
> 
> I am not sure what you mean here. Your .config below seems contains all the
> options including the non-selected one.
>
> Also, this still not solving the problem raised by Andrew regarding keep them
> updated.

It does not have all the options: it only contains the non-default
options as per Juergen's suggestion:

https://marc.info/?l=xen-devel&m=152419926530183


> It might be easier to maintain if we provide a per platform config option (e.g
> CONFIG_RCAR3) that will select driver for that specific board.
> 
> The user is then free to select other components (e.g scheduler...). So you
> don't impose memaccess disabled, NULL scheduler...
> 
> (Thank you Andrii for the suggestion!)

This is a good idea, it would be great to have CONFIG_RCAR3, but it does
not take away the need for this kconfig. CONFIG_RCAR3 and rcar3.config
are orthogonal, let me explain.

Let's say that we have a CONFIG_RCAR3 that selects everything needed for
the Rcar3, such as:

NR_CPUS, SCIF

and deselects:

ACPI, GICV3, the other UARTs, ARM_SMMU.

We still need a reference kconfig with other not platform specific
options, for instance:

SCHED_NULL

For two reasons:
1) we need a reference kconfig for certifications, it has to include the
   choice of schedulers, debug options, etc, which are not Rcar3 specific
2) as per previous discussions, we need a set of pre-canned kconfigs to
   establish what we security support

rcar3.config is meant to address these two points. CONFIG_RCAR3 would
not take away the need for rcar3.config, but it would make rcar3.config
shorter and easier to maintain.

CONFIG_RCAR3 was not on my roadmap but I'll see what I can do. Maybe it
is best if I do the work for QEMU only (both CONFIG_QEMU and
qemu.config) and leave the Renesas work (both CONFIG_RCAR3 and
rcar3.config) to EPAM. I cannot test it anyway.

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

Re: [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3

[Julien Grall]

Hi,

On 22/05/2018 22:00, Stefano Stabellini wrote:
> On Tue, 22 May 2018, Julien Grall wrote:
>> Hi,
>>
>> On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
>>> This is a reference tiny kconfig for Renesas RCar.  In terms of
>>> schedulers, it selects credit and NULL only.  It enables all the ARM64
>>> errata.
>>
>> It still does not feel right that you select only credit and NULL. Why not
>> credit2 and NULL? Or other combination.
> 
> We have to pick a combination of options for certifications and this is
> the one I am proposing: we need the null scheduler for latency sensitive
> mission critical VMs and we need credit (the default today) for the
> others.
> 
> I am happy to discuss the pros and cons of other combinations.

The .config is very subjective and I don't think we can possible cater 
everyone here. For instance, someone might want a different .config for 
that board with credit2... If someone ask for adding this option, what 
would you answer to them? You can't turn them down because this .config 
is for certification.

But I don't think your solution is the right way to go. See more below 
for some suggestion.

> 
>   
>>> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
>>> CC: artem_mygaiev@epam.com
>>> CC: volodymyr_babchuk@epam.com
>>>
>>> ---
>>>
>>> This patch is untested on Renesas RCar, please test!
>>> Also, I am not sure whether some of the errata workarounds can be
>>> disabled on the RCar.
>>>
>>> Changes in v2:
>>> - rename to rcar3
>>> - only add required symbols, let the defauls take care of the rest
>>
>> I am not sure what you mean here. Your .config below seems contains all the
>> options including the non-selected one.
>>
>> Also, this still not solving the problem raised by Andrew regarding keep them
>> updated.
> 
> It does not have all the options: it only contains the non-default
> options as per Juergen's suggestion:
> 
> https://marc.info/?l=xen-devel&m=152419926530183

Are you sure? For instance, CONFIG_ACPI is turned off by default but 
still present in the .config. Maybe I am missing something.

> 
> 
>> It might be easier to maintain if we provide a per platform config option (e.g
>> CONFIG_RCAR3) that will select driver for that specific board.
>>
>> The user is then free to select other components (e.g scheduler...). So you
>> don't impose memaccess disabled, NULL scheduler...
>>
>> (Thank you Andrii for the suggestion!)
> 
> This is a good idea, it would be great to have CONFIG_RCAR3, but it does
> not take away the need for this kconfig. CONFIG_RCAR3 and rcar3.config
> are orthogonal, let me explain.
> 
> Let's say that we have a CONFIG_RCAR3 that selects everything needed for
> the Rcar3, such as:
> 
> NR_CPUS, SCIF
> 
> and deselects:
> 
> ACPI, GICV3, the other UARTs, ARM_SMMU.
> 
> We still need a reference kconfig with other not platform specific
> options, for instance:
> 
> SCHED_NULL
> 
> For two reasons:
> 1) we need a reference kconfig for certifications, it has to include the
>     choice of schedulers, debug options, etc, which are not Rcar3 specific

As you said it is not Rcar3 specific. So this would have to be 
duplicated on each .config (QEMU...).

It really feels like we want some sort of partial .config (similar to 
what Linux has [1]) that will select non-specific platform option. We 
could have a tiny one, certifiable, "all", server...

> 2) as per previous discussions, we need a set of pre-canned kconfigs to
>     establish what we security support
> 
> rcar3.config is meant to address these two points. CONFIG_RCAR3 would
> not take away the need for rcar3.config, but it would make rcar3.config
> shorter and easier to maintain.
> 
> CONFIG_RCAR3 was not on my roadmap but I'll see what I can do. Maybe it
> is best if I do the work for QEMU only (both CONFIG_QEMU and
> qemu.config) and leave the Renesas work (both CONFIG_RCAR3 and
> rcar3.config) to EPAM. I cannot test it anyway.
> 

Cheers,

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/configs

-- 
Julien Grall

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

Re: [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3

[Stefano Stabellini]

On Tue, 22 May 2018, Julien Grall wrote:
> Hi,
> 
> On 22/05/2018 22:00, Stefano Stabellini wrote:
> > On Tue, 22 May 2018, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > > > This is a reference tiny kconfig for Renesas RCar.  In terms of
> > > > schedulers, it selects credit and NULL only.  It enables all the ARM64
> > > > errata.
> > > 
> > > It still does not feel right that you select only credit and NULL. Why not
> > > credit2 and NULL? Or other combination.
> > 
> > We have to pick a combination of options for certifications and this is
> > the one I am proposing: we need the null scheduler for latency sensitive
> > mission critical VMs and we need credit (the default today) for the
> > others.
> > 
> > I am happy to discuss the pros and cons of other combinations.
> 
> The .config is very subjective and I don't think we can possible cater
> everyone here. For instance, someone might want a different .config for that
> board with credit2... If someone ask for adding this option, what would you
> answer to them? You can't turn them down because this .config is for
> certification.
> 
> But I don't think your solution is the right way to go. See more below for
> some suggestion.
> 
> > 
> >   
> > > > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> > > > CC: artem_mygaiev@epam.com
> > > > CC: volodymyr_babchuk@epam.com
> > > > 
> > > > ---
> > > > 
> > > > This patch is untested on Renesas RCar, please test!
> > > > Also, I am not sure whether some of the errata workarounds can be
> > > > disabled on the RCar.
> > > > 
> > > > Changes in v2:
> > > > - rename to rcar3
> > > > - only add required symbols, let the defauls take care of the rest
> > > 
> > > I am not sure what you mean here. Your .config below seems contains all
> > > the
> > > options including the non-selected one.
> > > 
> > > Also, this still not solving the problem raised by Andrew regarding keep
> > > them
> > > updated.
> > 
> > It does not have all the options: it only contains the non-default
> > options as per Juergen's suggestion:
> > 
> > https://marc.info/?l=xen-devel&m=152419926530183
> 
> Are you sure? For instance, CONFIG_ACPI is turned off by default but still
> present in the .config. Maybe I am missing something.

That was my mistake.  The process of removing everything but the
non-default options was manual, I might have missed a couple of other
things. I don't know if there is a better way.


> > > It might be easier to maintain if we provide a per platform config option
> > > (e.g
> > > CONFIG_RCAR3) that will select driver for that specific board.
> > > 
> > > The user is then free to select other components (e.g scheduler...). So
> > > you
> > > don't impose memaccess disabled, NULL scheduler...
> > > 
> > > (Thank you Andrii for the suggestion!)
> > 
> > This is a good idea, it would be great to have CONFIG_RCAR3, but it does
> > not take away the need for this kconfig. CONFIG_RCAR3 and rcar3.config
> > are orthogonal, let me explain.
> > 
> > Let's say that we have a CONFIG_RCAR3 that selects everything needed for
> > the Rcar3, such as:
> > 
> > NR_CPUS, SCIF
> > 
> > and deselects:
> > 
> > ACPI, GICV3, the other UARTs, ARM_SMMU.
> > 
> > We still need a reference kconfig with other not platform specific
> > options, for instance:
> > 
> > SCHED_NULL
> > 
> > For two reasons:
> > 1) we need a reference kconfig for certifications, it has to include the
> >     choice of schedulers, debug options, etc, which are not Rcar3 specific
> 
> As you said it is not Rcar3 specific. So this would have to be duplicated on
> each .config (QEMU...).
> 
> It really feels like we want some sort of partial .config (similar to what
> Linux has [1]) that will select non-specific platform option. We could have a
> tiny one, certifiable, "all", server...

Uhm... This is a good suggestion! Following on this line of thinking, is
the idea that the user would:

1) cp configs/certifiable.config .config
2) make olddefconfig # this set to default any missing options
3) make menuconfig -> enable CONFIG_RCAR3
4) make

?

This way, tiny.config doesn't have to have all options, only the
non-default. CONFIG_RCAR3 takes care of enabling the platform specific
stuff.

This could actually work :-)


> > 2) as per previous discussions, we need a set of pre-canned kconfigs to
> >     establish what we security support
> > 
> > rcar3.config is meant to address these two points. CONFIG_RCAR3 would
> > not take away the need for rcar3.config, but it would make rcar3.config
> > shorter and easier to maintain.
> > 
> > CONFIG_RCAR3 was not on my roadmap but I'll see what I can do. Maybe it
> > is best if I do the work for QEMU only (both CONFIG_QEMU and
> > qemu.config) and leave the Renesas work (both CONFIG_RCAR3 and
> > rcar3.config) to EPAM. I cannot test it anyway.
> > 
> 
> Cheers,
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/configs

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

Re: [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3

[Artem Mygaiev]

Hi Stefano

On 23.05.18 00:00, Stefano Stabellini wrote:
> On Tue, 22 May 2018, Julien Grall wrote:
>> It might be easier to maintain if we provide a per platform config option (e.g
>> CONFIG_RCAR3) that will select driver for that specific board.
>>
>> The user is then free to select other components (e.g scheduler...). So you
>> don't impose memaccess disabled, NULL scheduler...
>>
>> (Thank you Andrii for the suggestion!)
> 
> This is a good idea, it would be great to have CONFIG_RCAR3, but it does
> not take away the need for this kconfig. CONFIG_RCAR3 and rcar3.config
> are orthogonal, let me explain.
> 
> Let's say that we have a CONFIG_RCAR3 that selects everything needed for
> the Rcar3, such as:
> 
> NR_CPUS, SCIF
> 
> and deselects:
> 
> ACPI, GICV3, the other UARTs, ARM_SMMU.
> 
> We still need a reference kconfig with other not platform specific
> options, for instance:
> 
> SCHED_NULL
> 
> For two reasons:
> 1) we need a reference kconfig for certifications, it has to include the
>     choice of schedulers, debug options, etc, which are not Rcar3 specific
> 2) as per previous discussions, we need a set of pre-canned kconfigs to
>     establish what we security support
> 
> rcar3.config is meant to address these two points. CONFIG_RCAR3 would
> not take away the need for rcar3.config, but it would make rcar3.config
> shorter and easier to maintain.
> 
> CONFIG_RCAR3 was not on my roadmap but I'll see what I can do. Maybe it
> is best if I do the work for QEMU only (both CONFIG_QEMU and
> qemu.config) and leave the Renesas work (both CONFIG_RCAR3 and
> rcar3.config) to EPAM. I cannot test it anyway.
>

We will check v3 patchset on R-Car H3

  -- Artem

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

[PATCH v2 09/10] arm: add a small kconfig for qemu-system-aarch64

[Stefano Stabellini]

Disable erratas because they don't apply to QEMU's software emulated
CPUs.

Arbitrarily choose a limit of 4 CPUs.

Select the credit and NULL schedulers only.

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes in v2:
- only add required symbols, let the defauls take care of the rest
---
 xen/arch/arm/configs/qemu.config | 53 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 xen/arch/arm/configs/qemu.config

diff --git a/xen/arch/arm/configs/qemu.config b/xen/arch/arm/configs/qemu.config
new file mode 100644
index 0000000..0a1e53a
--- /dev/null
+++ b/xen/arch/arm/configs/qemu.config
@@ -0,0 +1,53 @@
+CONFIG_ARM_64=y
+CONFIG_ARM=y
+
+#
+# Architecture Features
+#
+CONFIG_NR_CPUS=4
+# CONFIG_ACPI is not set
+CONFIG_GICV3=y
+# CONFIG_MEM_ACCESS is not set
+# CONFIG_SBSA_VUART_CONSOLE is not set
+
+#
+# ARM errata workaround via the alternative framework
+#
+# CONFIG_ARM64_ERRATUM_827319 is not set
+# CONFIG_ARM64_ERRATUM_824069 is not set
+# CONFIG_ARM64_ERRATUM_819472 is not set
+# CONFIG_ARM64_ERRATUM_832075 is not set
+# CONFIG_ARM64_ERRATUM_834220 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_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set
+
+#
+# Device Drivers
+#
+# CONFIG_NS16550 is not set
+# CONFIG_CADENCE_UART is not set
+# CONFIG_MVEBU is not set
+CONFIG_PL011=y
+# CONFIG_SCIF is not set
+# CONFIG_EHCI is not set
+# CONFIG_SMMUv2 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

[PATCH v2 10/10] xen: add cloc target

[Stefano Stabellini]

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>
CC: jbeulich@suse.com
CC: andrew.cooper3@citrix.com
---
Changes in v2:
- change implementation to use .o.d to find built source files
---
 xen/Makefile | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/xen/Makefile b/xen/Makefile
index 62d479c..7a56742 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -267,3 +267,14 @@ $(KCONFIG_CONFIG):
 include/config/auto.conf.cmd: ;
 
 -include $(BASEDIR)/include/config/auto.conf.cmd
+
+.PHONY: cloc
+cloc: build
+	$(eval tmpfile := $(shell mktemp))
+	$(foreach f, $(shell find $(BASEDIR) -name *.o.d), \
+		$(eval path := $(dir $(f))) \
+		$(eval name := $(shell cat $(f) | head -1 | cut -d " " -f 2)) \
+		$(shell if test -f $(path)/$(name) ; then echo $(path)/$(name) >> $(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

Re: [PATCH v2 10/10] xen: add cloc target

[Jan Beulich]

>>> On 22.05.18 at 02:53, <sstabellini@kernel.org> wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -267,3 +267,14 @@ $(KCONFIG_CONFIG):
>  include/config/auto.conf.cmd: ;
>  
>  -include $(BASEDIR)/include/config/auto.conf.cmd
> +
> +.PHONY: cloc
> +cloc: build

Not sure here - wouldn't it be reasonable to have no dependency here at
all, and just have the rule act on whatever is in the tree at present (from
whatever prior invocation of make)?

> +	$(eval tmpfile := $(shell mktemp))
> +	$(foreach f, $(shell find $(BASEDIR) -name *.o.d), \
> +		$(eval path := $(dir $(f))) \
> +		$(eval name := $(shell cat $(f) | head -1 | cut -d " " -f 2)) \
> +		$(shell if test -f $(path)/$(name) ; then echo $(path)/$(name) >> $(tmpfile); fi;))
> +	cloc --list-file=$(tmpfile)
> +	rm $(tmpfile)

I think you also want to "rm -f $(tmpfile)" first thing in case a prior "make cloc"
was interrupted.

Jan



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

Re: [PATCH v2 10/10] xen: add cloc target

[Stefano Stabellini]

On Tue, 22 May 2018, Jan Beulich wrote:
> >>> On 22.05.18 at 02:53, <sstabellini@kernel.org> wrote:
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -267,3 +267,14 @@ $(KCONFIG_CONFIG):
> >  include/config/auto.conf.cmd: ;
> >  
> >  -include $(BASEDIR)/include/config/auto.conf.cmd
> > +
> > +.PHONY: cloc
> > +cloc: build
> 
> Not sure here - wouldn't it be reasonable to have no dependency here at
> all, and just have the rule act on whatever is in the tree at present (from
> whatever prior invocation of make)?

This is a target for people that know what they are doing, so it makes
sense. I'll remove build as dependency.


> > +	$(eval tmpfile := $(shell mktemp))
> > +	$(foreach f, $(shell find $(BASEDIR) -name *.o.d), \
> > +		$(eval path := $(dir $(f))) \
> > +		$(eval name := $(shell cat $(f) | head -1 | cut -d " " -f 2)) \
> > +		$(shell if test -f $(path)/$(name) ; then echo $(path)/$(name) >> $(tmpfile); fi;))
> > +	cloc --list-file=$(tmpfile)
> > +	rm $(tmpfile)
> 
> I think you also want to "rm -f $(tmpfile)" first thing in case a prior "make cloc"
> was interrupted.

The issue is that tmpfile will be different the second time around
(mktemp returning a new name) so it is not quite possible to remove the
old tmpfile.

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

Re: [PATCH v2 10/10] xen: add cloc target

[Jan Beulich]

>>> On 22.05.18 at 22:08, <sstabellini@kernel.org> wrote:
> On Tue, 22 May 2018, Jan Beulich wrote:
>> >>> On 22.05.18 at 02:53, <sstabellini@kernel.org> wrote:
>> > +	$(eval tmpfile := $(shell mktemp))
>> > +	$(foreach f, $(shell find $(BASEDIR) -name *.o.d), \
>> > +		$(eval path := $(dir $(f))) \
>> > +		$(eval name := $(shell cat $(f) | head -1 | cut -d " " -f 2)) \
>> > +		$(shell if test -f $(path)/$(name) ; then echo $(path)/$(name) >> $(tmpfile); fi;))
>> > +	cloc --list-file=$(tmpfile)
>> > +	rm $(tmpfile)
>> 
>> I think you also want to "rm -f $(tmpfile)" first thing in case a prior "make cloc"
>> was interrupted.
> 
> The issue is that tmpfile will be different the second time around
> (mktemp returning a new name) so it is not quite possible to remove the
> old tmpfile.

Oh, I'm sorry for the noise - I should have paid attention to the very
first line of what is still quoted of your patch above.

Instead you then have the problem of the temporary file not being cleaned
up when interrupting "make cloc". Granted there are many other cases
where such files don't get cleaned up (judging from a look at my one /tmp),
but it'd be nice if we didn't contribute to the problem.

Jan



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

Re: [PATCH v2 10/10] xen: add cloc target

[Stefano Stabellini]

On Wed, 23 May 2018, Jan Beulich wrote:
> >>> On 22.05.18 at 22:08, <sstabellini@kernel.org> wrote:
> > On Tue, 22 May 2018, Jan Beulich wrote:
> >> >>> On 22.05.18 at 02:53, <sstabellini@kernel.org> wrote:
> >> > +	$(eval tmpfile := $(shell mktemp))
> >> > +	$(foreach f, $(shell find $(BASEDIR) -name *.o.d), \
> >> > +		$(eval path := $(dir $(f))) \
> >> > +		$(eval name := $(shell cat $(f) | head -1 | cut -d " " -f 2)) \
> >> > +		$(shell if test -f $(path)/$(name) ; then echo $(path)/$(name) >> $(tmpfile); fi;))
> >> > +	cloc --list-file=$(tmpfile)
> >> > +	rm $(tmpfile)
> >> 
> >> I think you also want to "rm -f $(tmpfile)" first thing in case a prior "make cloc"
> >> was interrupted.
> > 
> > The issue is that tmpfile will be different the second time around
> > (mktemp returning a new name) so it is not quite possible to remove the
> > old tmpfile.
> 
> Oh, I'm sorry for the noise - I should have paid attention to the very
> first line of what is still quoted of your patch above.
> 
> Instead you then have the problem of the temporary file not being cleaned
> up when interrupting "make cloc". Granted there are many other cases
> where such files don't get cleaned up (judging from a look at my one /tmp),
> but it'd be nice if we didn't contribute to the problem.

Given that tmpfile will be quite small, I think it is best to keep using
mktemp and risk leaking it. However, if you prefer, I can switch to
using a well-known filename, such as "sourcelist" to avoid leaks in case
of Ctrl-C during make.

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

Re: [PATCH v2 10/10] xen: add cloc target

[Jan Beulich]

>>> On 23.05.18 at 20:21, <sstabellini@kernel.org> wrote:
> On Wed, 23 May 2018, Jan Beulich wrote:
>> >>> On 22.05.18 at 22:08, <sstabellini@kernel.org> wrote:
>> > On Tue, 22 May 2018, Jan Beulich wrote:
>> >> >>> On 22.05.18 at 02:53, <sstabellini@kernel.org> wrote:
>> >> > +	$(eval tmpfile := $(shell mktemp))
>> >> > +	$(foreach f, $(shell find $(BASEDIR) -name *.o.d), \
>> >> > +		$(eval path := $(dir $(f))) \
>> >> > +		$(eval name := $(shell cat $(f) | head -1 | cut -d " " -f 2)) \
>> >> > +		$(shell if test -f $(path)/$(name) ; then echo $(path)/$(name) >> $(tmpfile); fi;))
>> >> > +	cloc --list-file=$(tmpfile)
>> >> > +	rm $(tmpfile)
>> >> 
>> >> I think you also want to "rm -f $(tmpfile)" first thing in case a prior "make cloc"
>> >> was interrupted.
>> > 
>> > The issue is that tmpfile will be different the second time around
>> > (mktemp returning a new name) so it is not quite possible to remove the
>> > old tmpfile.
>> 
>> Oh, I'm sorry for the noise - I should have paid attention to the very
>> first line of what is still quoted of your patch above.
>> 
>> Instead you then have the problem of the temporary file not being cleaned
>> up when interrupting "make cloc". Granted there are many other cases
>> where such files don't get cleaned up (judging from a look at my one /tmp),
>> but it'd be nice if we didn't contribute to the problem.
> 
> Given that tmpfile will be quite small, I think it is best to keep using
> mktemp and risk leaking it. However, if you prefer, I can switch to
> using a well-known filename, such as "sourcelist" to avoid leaks in case
> of Ctrl-C during make.

I'll leave that decision to you; I don't expect to be affected by this myself.

Jan



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

Re: [PATCH v2 10/10] xen: add cloc target

[Stefano Stabellini]

On Thu, 24 May 2018, Jan Beulich wrote:
> >>> On 23.05.18 at 20:21, <sstabellini@kernel.org> wrote:
> > On Wed, 23 May 2018, Jan Beulich wrote:
> >> >>> On 22.05.18 at 22:08, <sstabellini@kernel.org> wrote:
> >> > On Tue, 22 May 2018, Jan Beulich wrote:
> >> >> >>> On 22.05.18 at 02:53, <sstabellini@kernel.org> wrote:
> >> >> > +	$(eval tmpfile := $(shell mktemp))
> >> >> > +	$(foreach f, $(shell find $(BASEDIR) -name *.o.d), \
> >> >> > +		$(eval path := $(dir $(f))) \
> >> >> > +		$(eval name := $(shell cat $(f) | head -1 | cut -d " " -f 2)) \
> >> >> > +		$(shell if test -f $(path)/$(name) ; then echo $(path)/$(name) >> $(tmpfile); fi;))
> >> >> > +	cloc --list-file=$(tmpfile)
> >> >> > +	rm $(tmpfile)
> >> >> 
> >> >> I think you also want to "rm -f $(tmpfile)" first thing in case a prior "make cloc"
> >> >> was interrupted.
> >> > 
> >> > The issue is that tmpfile will be different the second time around
> >> > (mktemp returning a new name) so it is not quite possible to remove the
> >> > old tmpfile.
> >> 
> >> Oh, I'm sorry for the noise - I should have paid attention to the very
> >> first line of what is still quoted of your patch above.
> >> 
> >> Instead you then have the problem of the temporary file not being cleaned
> >> up when interrupting "make cloc". Granted there are many other cases
> >> where such files don't get cleaned up (judging from a look at my one /tmp),
> >> but it'd be nice if we didn't contribute to the problem.
> > 
> > Given that tmpfile will be quite small, I think it is best to keep using
> > mktemp and risk leaking it. However, if you prefer, I can switch to
> > using a well-known filename, such as "sourcelist" to avoid leaks in case
> > of Ctrl-C during make.
> 
> I'll leave that decision to you; I don't expect to be affected by this myself.

All right. In that case I'll keep mktemp as I did in v3. Thanks for the
review.

- Stefano

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