* [PATCH v2 0/10] arm: more kconfig configurability and small default configs
@ 2018-05-22 0:52 Stefano Stabellini
2018-05-22 0:53 ` [PATCH v2 01/10] arm: remove the ARM HDLCD driver Stefano Stabellini
` (9 more replies)
0 siblings, 10 replies; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 0:52 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
xen-devel
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH v2 01/10] arm: remove the ARM HDLCD driver
2018-05-22 0:52 [PATCH v2 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
@ 2018-05-22 0:53 ` Stefano Stabellini
2018-05-22 8:44 ` Julien Grall
2018-05-22 0:53 ` [PATCH v2 02/10] arm: make it possible to disable more kconfig options Stefano Stabellini
` (8 subsequent siblings)
9 siblings, 1 reply; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 0:53 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
xen-devel
The ARM HDLCD driver is unused. The device itself can only be found on
Virtual Express boards that are for early development only. Remove the
driver.
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
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH v2 02/10] arm: make it possible to disable more kconfig options
2018-05-22 0:52 [PATCH v2 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
2018-05-22 0:53 ` [PATCH v2 01/10] arm: remove the ARM HDLCD driver Stefano Stabellini
@ 2018-05-22 0:53 ` Stefano Stabellini
2018-05-22 8:45 ` Julien Grall
2018-05-22 9:05 ` Julien Grall
2018-05-22 0:53 ` [PATCH v2 03/10] Rename HAS_MEM_ACCESS to MEM_ACCESS Stefano Stabellini
` (7 subsequent siblings)
9 siblings, 2 replies; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 0:53 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
xen-devel
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
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH v2 03/10] Rename HAS_MEM_ACCESS to MEM_ACCESS
2018-05-22 0:52 [PATCH v2 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
2018-05-22 0:53 ` [PATCH v2 01/10] arm: remove the ARM HDLCD driver Stefano Stabellini
2018-05-22 0:53 ` [PATCH v2 02/10] arm: make it possible to disable more kconfig options Stefano Stabellini
@ 2018-05-22 0:53 ` Stefano Stabellini
2018-05-22 6:27 ` Jan Beulich
2018-05-22 0:53 ` [PATCH v2 04/10] arm: rename HAS_GICV3 to GICV3 Stefano Stabellini
` (6 subsequent siblings)
9 siblings, 1 reply; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 0:53 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov,
George.Dunlap, andrew.cooper3, ian.jackson, dfaggioli, tim,
jbeulich, wei.liu2, xen-devel
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
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH v2 04/10] arm: rename HAS_GICV3 to GICV3
2018-05-22 0:52 [PATCH v2 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
` (2 preceding siblings ...)
2018-05-22 0:53 ` [PATCH v2 03/10] Rename HAS_MEM_ACCESS to MEM_ACCESS Stefano Stabellini
@ 2018-05-22 0:53 ` Stefano Stabellini
2018-05-22 0:53 ` [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers Stefano Stabellini
` (5 subsequent siblings)
9 siblings, 0 replies; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 0:53 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
xen-devel
HAS_GICV3 has become selectable by the user. To mark the change, rename
the option from HAS_GICV3 to GICV3.
Suggested-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
---
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
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers
2018-05-22 0:52 [PATCH v2 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
` (3 preceding siblings ...)
2018-05-22 0:53 ` [PATCH v2 04/10] arm: rename HAS_GICV3 to GICV3 Stefano Stabellini
@ 2018-05-22 0:53 ` Stefano Stabellini
2018-05-22 6:34 ` Jan Beulich
2018-05-22 0:53 ` [PATCH v2 06/10] xen: remove HAS_ prefix from UART Kconfig options Stefano Stabellini
` (4 subsequent siblings)
9 siblings, 1 reply; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 0:53 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
xen-devel
All the UART drivers are silent options. Add one line descriptions so
that can be de/selected via menuconfig.
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
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH v2 06/10] xen: remove HAS_ prefix from UART Kconfig options
2018-05-22 0:52 [PATCH v2 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
` (4 preceding siblings ...)
2018-05-22 0:53 ` [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers Stefano Stabellini
@ 2018-05-22 0:53 ` Stefano Stabellini
2018-05-22 6:35 ` Jan Beulich
2018-05-22 0:53 ` [PATCH v2 07/10] arm: make it possible to disable the SMMU driver Stefano Stabellini
` (3 subsequent siblings)
9 siblings, 1 reply; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 0:53 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov,
George.Dunlap, andrew.cooper3, ian.jackson, dfaggioli, tim,
jbeulich, wei.liu2, xen-devel
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
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH v2 07/10] arm: make it possible to disable the SMMU driver
2018-05-22 0:52 [PATCH v2 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
` (5 preceding siblings ...)
2018-05-22 0:53 ` [PATCH v2 06/10] xen: remove HAS_ prefix from UART Kconfig options Stefano Stabellini
@ 2018-05-22 0:53 ` Stefano Stabellini
2018-05-22 6:38 ` Jan Beulich
2018-05-22 9:03 ` Julien Grall
2018-05-22 0:53 ` [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3 Stefano Stabellini
` (2 subsequent siblings)
9 siblings, 2 replies; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 0:53 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
jbeulich, xen-devel
Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
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
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3
2018-05-22 0:52 [PATCH v2 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
` (6 preceding siblings ...)
2018-05-22 0:53 ` [PATCH v2 07/10] arm: make it possible to disable the SMMU driver Stefano Stabellini
@ 2018-05-22 0:53 ` Stefano Stabellini
2018-05-22 9:22 ` Julien Grall
2018-05-22 0:53 ` [PATCH v2 09/10] arm: add a small kconfig for qemu-system-aarch64 Stefano Stabellini
2018-05-22 0:53 ` [PATCH v2 10/10] xen: add cloc target Stefano Stabellini
9 siblings, 1 reply; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 0:53 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
xen-devel, volodymyr_babchuk
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
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH v2 09/10] arm: add a small kconfig for qemu-system-aarch64
2018-05-22 0:52 [PATCH v2 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
` (7 preceding siblings ...)
2018-05-22 0:53 ` [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3 Stefano Stabellini
@ 2018-05-22 0:53 ` Stefano Stabellini
2018-05-22 0:53 ` [PATCH v2 10/10] xen: add cloc target Stefano Stabellini
9 siblings, 0 replies; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 0:53 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, dfaggioli,
xen-devel
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
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH v2 10/10] xen: add cloc target
2018-05-22 0:52 [PATCH v2 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
` (8 preceding siblings ...)
2018-05-22 0:53 ` [PATCH v2 09/10] arm: add a small kconfig for qemu-system-aarch64 Stefano Stabellini
@ 2018-05-22 0:53 ` Stefano Stabellini
2018-05-22 9:08 ` Jan Beulich
9 siblings, 1 reply; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 0:53 UTC (permalink / raw)
To: julien.grall
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov,
andrew.cooper3, dfaggioli, jbeulich, xen-devel
Add a Xen build target to count the lines of code of the source files
built. Uses `cloc' to do the job.
With Xen on ARM taking off in embedded, IoT, and automotive, we are
seeing more and more uses of Xen in constrained environments. Users and
system integrators want the smallest Xen and Dom0 configurations. Some
of these deployments require certifications, where you definitely want
the smallest lines of code count. I provided this patch to give us the
lines of code count for that purpose.
Use the .o.d files to account for all the built source files. Generate a
list for the `cloc' utility and invoke `cloc'.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
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
^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [PATCH v2 03/10] Rename HAS_MEM_ACCESS to MEM_ACCESS
2018-05-22 0:53 ` [PATCH v2 03/10] Rename HAS_MEM_ACCESS to MEM_ACCESS Stefano Stabellini
@ 2018-05-22 6:27 ` Jan Beulich
2018-05-22 22:08 ` Stefano Stabellini
0 siblings, 1 reply; 43+ messages in thread
From: Jan Beulich @ 2018-05-22 6:27 UTC (permalink / raw)
To: sstabellini
Cc: artem_mygaiev, lars.kurth, wei.liu2, George.Dunlap,
andrew.cooper3, ian.jackson, xen-devel, julien.grall, tim,
andrii_anisov, Dario Faggioli
>>> 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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers
2018-05-22 0:53 ` [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers Stefano Stabellini
@ 2018-05-22 6:34 ` Jan Beulich
2018-05-22 8:51 ` Julien Grall
2018-05-22 19:40 ` Stefano Stabellini
0 siblings, 2 replies; 43+ messages in thread
From: Jan Beulich @ 2018-05-22 6:34 UTC (permalink / raw)
To: sstabellini
Cc: artem_mygaiev, lars.kurth, andrii_anisov, Dario Faggioli,
julien.grall, xen-devel
>>> 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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 06/10] xen: remove HAS_ prefix from UART Kconfig options
2018-05-22 0:53 ` [PATCH v2 06/10] xen: remove HAS_ prefix from UART Kconfig options Stefano Stabellini
@ 2018-05-22 6:35 ` Jan Beulich
2018-05-22 22:23 ` Stefano Stabellini
0 siblings, 1 reply; 43+ messages in thread
From: Jan Beulich @ 2018-05-22 6:35 UTC (permalink / raw)
To: sstabellini
Cc: artem_mygaiev, lars.kurth, wei.liu2, George.Dunlap,
andrew.cooper3, ian.jackson, xen-devel, julien.grall, tim,
andrii_anisov, Dario Faggioli
>>> 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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 07/10] arm: make it possible to disable the SMMU driver
2018-05-22 0:53 ` [PATCH v2 07/10] arm: make it possible to disable the SMMU driver Stefano Stabellini
@ 2018-05-22 6:38 ` Jan Beulich
2018-05-22 20:05 ` Stefano Stabellini
2018-05-22 9:03 ` Julien Grall
1 sibling, 1 reply; 43+ messages in thread
From: Jan Beulich @ 2018-05-22 6:38 UTC (permalink / raw)
To: sstabellini
Cc: artem_mygaiev, lars.kurth, andrii_anisov, Dario Faggioli,
julien.grall, xen-devel
>--- 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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 01/10] arm: remove the ARM HDLCD driver
2018-05-22 0:53 ` [PATCH v2 01/10] arm: remove the ARM HDLCD driver Stefano Stabellini
@ 2018-05-22 8:44 ` Julien Grall
2018-05-22 19:55 ` Stefano Stabellini
0 siblings, 1 reply; 43+ messages in thread
From: Julien Grall @ 2018-05-22 8:44 UTC (permalink / raw)
To: Stefano Stabellini
Cc: artem_mygaiev, lars.kurth, dfaggioli, andrii_anisov, xen-devel
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 02/10] arm: make it possible to disable more kconfig options
2018-05-22 0:53 ` [PATCH v2 02/10] arm: make it possible to disable more kconfig options Stefano Stabellini
@ 2018-05-22 8:45 ` Julien Grall
2018-05-22 20:18 ` Stefano Stabellini
2018-05-22 9:05 ` Julien Grall
1 sibling, 1 reply; 43+ messages in thread
From: Julien Grall @ 2018-05-22 8:45 UTC (permalink / raw)
To: Stefano Stabellini
Cc: artem_mygaiev, lars.kurth, dfaggioli, andrii_anisov, xen-devel
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers
2018-05-22 6:34 ` Jan Beulich
@ 2018-05-22 8:51 ` Julien Grall
2018-05-22 9:22 ` Jan Beulich
2018-05-22 19:40 ` Stefano Stabellini
1 sibling, 1 reply; 43+ messages in thread
From: Julien Grall @ 2018-05-22 8:51 UTC (permalink / raw)
To: Jan Beulich, sstabellini
Cc: artem_mygaiev, lars.kurth, Dario Faggioli, andrii_anisov, xen-devel
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 07/10] arm: make it possible to disable the SMMU driver
2018-05-22 0:53 ` [PATCH v2 07/10] arm: make it possible to disable the SMMU driver Stefano Stabellini
2018-05-22 6:38 ` Jan Beulich
@ 2018-05-22 9:03 ` Julien Grall
2018-05-22 20:03 ` Stefano Stabellini
1 sibling, 1 reply; 43+ messages in thread
From: Julien Grall @ 2018-05-22 9:03 UTC (permalink / raw)
To: Stefano Stabellini
Cc: artem_mygaiev, lars.kurth, andrii_anisov, dfaggioli, jbeulich, xen-devel
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 02/10] arm: make it possible to disable more kconfig options
2018-05-22 0:53 ` [PATCH v2 02/10] arm: make it possible to disable more kconfig options Stefano Stabellini
2018-05-22 8:45 ` Julien Grall
@ 2018-05-22 9:05 ` Julien Grall
2018-05-22 20:20 ` Stefano Stabellini
1 sibling, 1 reply; 43+ messages in thread
From: Julien Grall @ 2018-05-22 9:05 UTC (permalink / raw)
To: Stefano Stabellini
Cc: artem_mygaiev, lars.kurth, dfaggioli, andrii_anisov, xen-devel
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 10/10] xen: add cloc target
2018-05-22 0:53 ` [PATCH v2 10/10] xen: add cloc target Stefano Stabellini
@ 2018-05-22 9:08 ` Jan Beulich
2018-05-22 20:08 ` Stefano Stabellini
0 siblings, 1 reply; 43+ messages in thread
From: Jan Beulich @ 2018-05-22 9:08 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Artem Mygaiev, Lars Kurth, andrii_anisov, Andrew Cooper,
xen-devel, Julien Grall, Dario Faggioli
>>> 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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers
2018-05-22 8:51 ` Julien Grall
@ 2018-05-22 9:22 ` Jan Beulich
2018-05-22 9:25 ` Julien Grall
0 siblings, 1 reply; 43+ messages in thread
From: Jan Beulich @ 2018-05-22 9:22 UTC (permalink / raw)
To: Julien Grall
Cc: Artem Mygaiev, Lars Kurth, Stefano Stabellini, andrii_anisov,
Dario Faggioli, xen-devel
>>> 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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3
2018-05-22 0:53 ` [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3 Stefano Stabellini
@ 2018-05-22 9:22 ` Julien Grall
2018-05-22 21:00 ` Stefano Stabellini
0 siblings, 1 reply; 43+ messages in thread
From: Julien Grall @ 2018-05-22 9:22 UTC (permalink / raw)
To: Stefano Stabellini
Cc: artem_mygaiev, lars.kurth, andrii_anisov, dfaggioli, xen-devel,
volodymyr_babchuk
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers
2018-05-22 9:22 ` Jan Beulich
@ 2018-05-22 9:25 ` Julien Grall
2018-05-22 9:37 ` Jan Beulich
0 siblings, 1 reply; 43+ messages in thread
From: Julien Grall @ 2018-05-22 9:25 UTC (permalink / raw)
To: Jan Beulich
Cc: Artem Mygaiev, Lars Kurth, Stefano Stabellini, andrii_anisov,
Dario Faggioli, xen-devel
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers
2018-05-22 9:25 ` Julien Grall
@ 2018-05-22 9:37 ` Jan Beulich
2018-05-22 12:59 ` Julien Grall
0 siblings, 1 reply; 43+ messages in thread
From: Jan Beulich @ 2018-05-22 9:37 UTC (permalink / raw)
To: Julien Grall
Cc: Artem Mygaiev, Lars Kurth, Stefano Stabellini, andrii_anisov,
Dario Faggioli, xen-devel
>>> 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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers
2018-05-22 9:37 ` Jan Beulich
@ 2018-05-22 12:59 ` Julien Grall
0 siblings, 0 replies; 43+ messages in thread
From: Julien Grall @ 2018-05-22 12:59 UTC (permalink / raw)
To: Jan Beulich
Cc: Artem Mygaiev, Lars Kurth, Stefano Stabellini, andrii_anisov,
Dario Faggioli, xen-devel
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers
2018-05-22 6:34 ` Jan Beulich
2018-05-22 8:51 ` Julien Grall
@ 2018-05-22 19:40 ` Stefano Stabellini
1 sibling, 0 replies; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 19:40 UTC (permalink / raw)
To: Jan Beulich
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, xen-devel,
julien.grall, Dario Faggioli
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 01/10] arm: remove the ARM HDLCD driver
2018-05-22 8:44 ` Julien Grall
@ 2018-05-22 19:55 ` Stefano Stabellini
0 siblings, 0 replies; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 19:55 UTC (permalink / raw)
To: Julien Grall
Cc: artem_mygaiev, lars.kurth, Stefano Stabellini, andrii_anisov,
dfaggioli, xen-devel
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 07/10] arm: make it possible to disable the SMMU driver
2018-05-22 9:03 ` Julien Grall
@ 2018-05-22 20:03 ` Stefano Stabellini
0 siblings, 0 replies; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 20:03 UTC (permalink / raw)
To: Julien Grall
Cc: artem_mygaiev, lars.kurth, Stefano Stabellini, andrii_anisov,
dfaggioli, jbeulich, xen-devel
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 07/10] arm: make it possible to disable the SMMU driver
2018-05-22 6:38 ` Jan Beulich
@ 2018-05-22 20:05 ` Stefano Stabellini
0 siblings, 0 replies; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 20:05 UTC (permalink / raw)
To: Jan Beulich
Cc: artem_mygaiev, lars.kurth, sstabellini, andrii_anisov, xen-devel,
julien.grall, Dario Faggioli
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 10/10] xen: add cloc target
2018-05-22 9:08 ` Jan Beulich
@ 2018-05-22 20:08 ` Stefano Stabellini
2018-05-23 7:51 ` Jan Beulich
0 siblings, 1 reply; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 20:08 UTC (permalink / raw)
To: Jan Beulich
Cc: Artem Mygaiev, Lars Kurth, Stefano Stabellini, andrii_anisov,
Andrew Cooper, xen-devel, Julien Grall, Dario Faggioli
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 02/10] arm: make it possible to disable more kconfig options
2018-05-22 8:45 ` Julien Grall
@ 2018-05-22 20:18 ` Stefano Stabellini
0 siblings, 0 replies; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 20:18 UTC (permalink / raw)
To: Julien Grall
Cc: artem_mygaiev, lars.kurth, Stefano Stabellini, andrii_anisov,
dfaggioli, xen-devel
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 02/10] arm: make it possible to disable more kconfig options
2018-05-22 9:05 ` Julien Grall
@ 2018-05-22 20:20 ` Stefano Stabellini
0 siblings, 0 replies; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 20:20 UTC (permalink / raw)
To: Julien Grall
Cc: artem_mygaiev, lars.kurth, Stefano Stabellini, andrii_anisov,
dfaggioli, xen-devel
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3
2018-05-22 9:22 ` Julien Grall
@ 2018-05-22 21:00 ` Stefano Stabellini
2018-05-22 21:57 ` Julien Grall
2018-05-23 8:26 ` Artem Mygaiev
0 siblings, 2 replies; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 21:00 UTC (permalink / raw)
To: Julien Grall
Cc: artem_mygaiev, lars.kurth, Stefano Stabellini, andrii_anisov,
dfaggioli, xen-devel, volodymyr_babchuk
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3
2018-05-22 21:00 ` Stefano Stabellini
@ 2018-05-22 21:57 ` Julien Grall
2018-05-22 22:53 ` Stefano Stabellini
2018-05-23 8:26 ` Artem Mygaiev
1 sibling, 1 reply; 43+ messages in thread
From: Julien Grall @ 2018-05-22 21:57 UTC (permalink / raw)
To: Stefano Stabellini
Cc: artem_mygaiev, lars.kurth, xen-devel, andrii_anisov, dfaggioli,
nd, volodymyr_babchuk
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 03/10] Rename HAS_MEM_ACCESS to MEM_ACCESS
2018-05-22 6:27 ` Jan Beulich
@ 2018-05-22 22:08 ` Stefano Stabellini
0 siblings, 0 replies; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 22:08 UTC (permalink / raw)
To: Jan Beulich
Cc: artem_mygaiev, lars.kurth, sstabellini, wei.liu2, George.Dunlap,
andrew.cooper3, ian.jackson, xen-devel, julien.grall, tim,
andrii_anisov, Dario Faggioli
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 06/10] xen: remove HAS_ prefix from UART Kconfig options
2018-05-22 6:35 ` Jan Beulich
@ 2018-05-22 22:23 ` Stefano Stabellini
0 siblings, 0 replies; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 22:23 UTC (permalink / raw)
To: Jan Beulich
Cc: artem_mygaiev, lars.kurth, sstabellini, wei.liu2, George.Dunlap,
andrew.cooper3, ian.jackson, xen-devel, julien.grall, tim,
andrii_anisov, Dario Faggioli
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3
2018-05-22 21:57 ` Julien Grall
@ 2018-05-22 22:53 ` Stefano Stabellini
0 siblings, 0 replies; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-22 22:53 UTC (permalink / raw)
To: Julien Grall
Cc: artem_mygaiev, lars.kurth, nd, Stefano Stabellini, andrii_anisov,
dfaggioli, xen-devel, volodymyr_babchuk
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 10/10] xen: add cloc target
2018-05-22 20:08 ` Stefano Stabellini
@ 2018-05-23 7:51 ` Jan Beulich
2018-05-23 18:21 ` Stefano Stabellini
0 siblings, 1 reply; 43+ messages in thread
From: Jan Beulich @ 2018-05-23 7:51 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Artem Mygaiev, Lars Kurth, andrii_anisov, Andrew Cooper,
xen-devel, Julien Grall, Dario Faggioli
>>> 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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3
2018-05-22 21:00 ` Stefano Stabellini
2018-05-22 21:57 ` Julien Grall
@ 2018-05-23 8:26 ` Artem Mygaiev
1 sibling, 0 replies; 43+ messages in thread
From: Artem Mygaiev @ 2018-05-23 8:26 UTC (permalink / raw)
To: Stefano Stabellini, Julien Grall
Cc: lars.kurth, dfaggioli, andrii_anisov, volodymyr_babchuk, xen-devel
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 10/10] xen: add cloc target
2018-05-23 7:51 ` Jan Beulich
@ 2018-05-23 18:21 ` Stefano Stabellini
2018-05-24 7:23 ` Jan Beulich
0 siblings, 1 reply; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-23 18:21 UTC (permalink / raw)
To: Jan Beulich
Cc: Artem Mygaiev, Lars Kurth, Stefano Stabellini, andrii_anisov,
Andrew Cooper, xen-devel, Julien Grall, Dario Faggioli
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 10/10] xen: add cloc target
2018-05-23 18:21 ` Stefano Stabellini
@ 2018-05-24 7:23 ` Jan Beulich
2018-05-24 18:41 ` Stefano Stabellini
0 siblings, 1 reply; 43+ messages in thread
From: Jan Beulich @ 2018-05-24 7:23 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Artem Mygaiev, Lars Kurth, andrii_anisov, Andrew Cooper,
xen-devel, Julien Grall, Dario Faggioli
>>> 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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2 10/10] xen: add cloc target
2018-05-24 7:23 ` Jan Beulich
@ 2018-05-24 18:41 ` Stefano Stabellini
0 siblings, 0 replies; 43+ messages in thread
From: Stefano Stabellini @ 2018-05-24 18:41 UTC (permalink / raw)
To: Jan Beulich
Cc: Artem Mygaiev, Lars Kurth, Stefano Stabellini, andrii_anisov,
Andrew Cooper, xen-devel, Julien Grall, Dario Faggioli
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
^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2018-05-24 18:41 UTC | newest]
Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-22 0:52 [PATCH v2 0/10] arm: more kconfig configurability and small default configs Stefano Stabellini
2018-05-22 0:53 ` [PATCH v2 01/10] arm: remove the ARM HDLCD driver Stefano Stabellini
2018-05-22 8:44 ` Julien Grall
2018-05-22 19:55 ` Stefano Stabellini
2018-05-22 0:53 ` [PATCH v2 02/10] arm: make it possible to disable more kconfig options Stefano Stabellini
2018-05-22 8:45 ` Julien Grall
2018-05-22 20:18 ` Stefano Stabellini
2018-05-22 9:05 ` Julien Grall
2018-05-22 20:20 ` Stefano Stabellini
2018-05-22 0:53 ` [PATCH v2 03/10] Rename HAS_MEM_ACCESS to MEM_ACCESS Stefano Stabellini
2018-05-22 6:27 ` Jan Beulich
2018-05-22 22:08 ` Stefano Stabellini
2018-05-22 0:53 ` [PATCH v2 04/10] arm: rename HAS_GICV3 to GICV3 Stefano Stabellini
2018-05-22 0:53 ` [PATCH v2 05/10] arm: make it possible to enable/disable UART drivers Stefano Stabellini
2018-05-22 6:34 ` Jan Beulich
2018-05-22 8:51 ` Julien Grall
2018-05-22 9:22 ` Jan Beulich
2018-05-22 9:25 ` Julien Grall
2018-05-22 9:37 ` Jan Beulich
2018-05-22 12:59 ` Julien Grall
2018-05-22 19:40 ` Stefano Stabellini
2018-05-22 0:53 ` [PATCH v2 06/10] xen: remove HAS_ prefix from UART Kconfig options Stefano Stabellini
2018-05-22 6:35 ` Jan Beulich
2018-05-22 22:23 ` Stefano Stabellini
2018-05-22 0:53 ` [PATCH v2 07/10] arm: make it possible to disable the SMMU driver Stefano Stabellini
2018-05-22 6:38 ` Jan Beulich
2018-05-22 20:05 ` Stefano Stabellini
2018-05-22 9:03 ` Julien Grall
2018-05-22 20:03 ` Stefano Stabellini
2018-05-22 0:53 ` [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3 Stefano Stabellini
2018-05-22 9:22 ` Julien Grall
2018-05-22 21:00 ` Stefano Stabellini
2018-05-22 21:57 ` Julien Grall
2018-05-22 22:53 ` Stefano Stabellini
2018-05-23 8:26 ` Artem Mygaiev
2018-05-22 0:53 ` [PATCH v2 09/10] arm: add a small kconfig for qemu-system-aarch64 Stefano Stabellini
2018-05-22 0:53 ` [PATCH v2 10/10] xen: add cloc target Stefano Stabellini
2018-05-22 9:08 ` Jan Beulich
2018-05-22 20:08 ` Stefano Stabellini
2018-05-23 7:51 ` Jan Beulich
2018-05-23 18:21 ` Stefano Stabellini
2018-05-24 7:23 ` Jan Beulich
2018-05-24 18:41 ` Stefano Stabellini
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.