* [PATCH 1/6] arm: make it possible to disable more kconfig options
2018-04-18 22:15 [PATCH 0/6] arm: more kconfig configurability and small default configs Stefano Stabellini
@ 2018-04-18 22:15 ` Stefano Stabellini
2018-04-19 15:36 ` Julien Grall
2018-04-18 22:15 ` [PATCH 2/6] arm: make it possible to enable/disable UART drivers Stefano Stabellini
` (7 subsequent siblings)
8 siblings, 1 reply; 50+ messages in thread
From: Stefano Stabellini @ 2018-04-18 22:15 UTC (permalink / raw)
To: julien.grall; +Cc: sstabellini, xen-devel
Make it possible to disable the following existing kconfig options:
HAS_GICV3
HAS_ARM_HDLCD
HAS_MEM_ACCESS
Today they are silent option. This patch adds one line descriptions and
make them de/selectable.
Also, do not select VIDEO: make HAS_ARM_HDLCD select VIDEO instead. In
fact, VIDEO is only needed by HAS_ARM_HDLCD.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
---
xen/arch/arm/Kconfig | 15 +++++++++++----
xen/drivers/video/Kconfig | 8 +++++++-
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 8174c0c..83963c8 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -12,17 +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_ARM_HDLCD
select HAS_DEVICE_TREE
- select HAS_MEM_ACCESS
select HAS_PASSTHROUGH
select HAS_PDX
- select VIDEO
config ARCH_DEFCONFIG
string
@@ -44,6 +40,17 @@ config ACPI
config HAS_GICV3
bool
+ prompt "GICv3 driver"
+ 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
diff --git a/xen/drivers/video/Kconfig b/xen/drivers/video/Kconfig
index 52e8ce6..26daf9a 100644
--- a/xen/drivers/video/Kconfig
+++ b/xen/drivers/video/Kconfig
@@ -13,4 +13,10 @@ config VGA
If unsure, say Y.
config HAS_ARM_HDLCD
- bool
+ bool "ARM HDLCD driver"
+ default n
+ select VIDEO
+ ---help---
+ Enable Xen video output to ARM HDLCD graphic controllers.
+
+ if unsure, say N.
--
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] 50+ messages in thread
* Re: [PATCH 1/6] arm: make it possible to disable more kconfig options
2018-04-18 22:15 ` [PATCH 1/6] arm: make it possible to disable more kconfig options Stefano Stabellini
@ 2018-04-19 15:36 ` Julien Grall
2018-05-21 19:58 ` Stefano Stabellini
0 siblings, 1 reply; 50+ messages in thread
From: Julien Grall @ 2018-04-19 15:36 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel
Hi Stefano,
On 18/04/18 23:15, Stefano Stabellini wrote:
> Make it possible to disable the following existing kconfig options:
> HAS_GICV3
> HAS_ARM_HDLCD
> HAS_MEM_ACCESS
>
> Today they are silent option. This patch adds one line descriptions and
> make them de/selectable.
>
> Also, do not select VIDEO: make HAS_ARM_HDLCD select VIDEO instead. In
> fact, VIDEO is only needed by HAS_ARM_HDLCD.
>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> xen/arch/arm/Kconfig | 15 +++++++++++----
> xen/drivers/video/Kconfig | 8 +++++++-
> 2 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 8174c0c..83963c8 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -12,17 +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_ARM_HDLCD
> select HAS_DEVICE_TREE
> - select HAS_MEM_ACCESS
> select HAS_PASSTHROUGH
> select HAS_PDX
> - select VIDEO
>
> config ARCH_DEFCONFIG
> string
> @@ -44,6 +40,17 @@ config ACPI
>
> config HAS_GICV3
> bool
> + prompt "GICv3 driver"
> + default y
That's quite different for the existing config. Now you select GICv3 for
arm32 which we know does not work.
Also, to bike-shed a bit, I feel HAS_* is more to say "we support" over
this is selectable by the user. So probably some renaming is required here.
> +
> +config HAS_MEM_ACCESS
> + bool
> + prompt "Memory Access and VM events"
> + default y
Most of the memaccess code is not protected by HAS_MEM_ACCESS. So you
are going to drop just a couple of hundreds line. Not sure if it is
worth it in the actual state.
> + ---help---
> +
> + Framework to configure memory access types for guests and receive
> + related events in userspace.
>
> config HAS_ITS
> bool
> diff --git a/xen/drivers/video/Kconfig b/xen/drivers/video/Kconfig
> index 52e8ce6..26daf9a 100644
> --- a/xen/drivers/video/Kconfig
> +++ b/xen/drivers/video/Kconfig
> @@ -13,4 +13,10 @@ config VGA
> If unsure, say Y.
>
> config HAS_ARM_HDLCD
To be honest I would just rip off the driver. I doubt anybody has been
using it for the past 5 years and only targets vexpress.
> - bool
> + bool "ARM HDLCD driver"
> + default n
> + select VIDEO
> + ---help---
> + Enable Xen video output to ARM HDLCD graphic controllers.
> +
> + if unsure, say N.
>
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] 50+ messages in thread
* Re: [PATCH 1/6] arm: make it possible to disable more kconfig options
2018-04-19 15:36 ` Julien Grall
@ 2018-05-21 19:58 ` Stefano Stabellini
2018-05-22 8:24 ` Julien Grall
0 siblings, 1 reply; 50+ messages in thread
From: Stefano Stabellini @ 2018-05-21 19:58 UTC (permalink / raw)
To: Julien Grall; +Cc: Stefano Stabellini, xen-devel
On Thu, 19 Apr 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 18/04/18 23:15, Stefano Stabellini wrote:
> > Make it possible to disable the following existing kconfig options:
> > HAS_GICV3
> > HAS_ARM_HDLCD
> > HAS_MEM_ACCESS
> >
> > Today they are silent option. This patch adds one line descriptions and
> > make them de/selectable.
> >
> > Also, do not select VIDEO: make HAS_ARM_HDLCD select VIDEO instead. In
> > fact, VIDEO is only needed by HAS_ARM_HDLCD.
> >
> > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> > ---
> > xen/arch/arm/Kconfig | 15 +++++++++++----
> > xen/drivers/video/Kconfig | 8 +++++++-
> > 2 files changed, 18 insertions(+), 5 deletions(-)
> >
> > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > index 8174c0c..83963c8 100644
> > --- a/xen/arch/arm/Kconfig
> > +++ b/xen/arch/arm/Kconfig
> > @@ -12,17 +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_ARM_HDLCD
> > select HAS_DEVICE_TREE
> > - select HAS_MEM_ACCESS
> > select HAS_PASSTHROUGH
> > select HAS_PDX
> > - select VIDEO
> > config ARCH_DEFCONFIG
> > string
> > @@ -44,6 +40,17 @@ config ACPI
> > config HAS_GICV3
> > bool
> > + prompt "GICv3 driver"
> > + default y
>
> That's quite different for the existing config. Now you select GICv3 for arm32
> which we know does not work.
Ah! I'll fix that.
> Also, to bike-shed a bit, I feel HAS_* is more to say "we support" over this
> is selectable by the user. So probably some renaming is required here.
OK, should I just remove the HAS_ prefix (for example HAS_GICV3 ->
GICV3) or do you have a better suggestion? In any case, I'll do in a
separate patch to make it easier to review.
> > +
> > +config HAS_MEM_ACCESS
> > + bool
> > + prompt "Memory Access and VM events"
> > + default y
>
> Most of the memaccess code is not protected by HAS_MEM_ACCESS. So you are
> going to drop just a couple of hundreds line. Not sure if it is worth it in
> the actual state.
Yes, the LOC count it is not worth it today, but I would still like to
make it selectable because I don't want Xen to come to rely on having
HAS_MEM_ACCESS enabled all the time. !MEM_ACCESS is a good and valid
configuration. Also, we can go forward in making more stuff protected by
HAS_MEM_ACCESS soon.
> > + ---help---
> > +
> > + Framework to configure memory access types for guests and receive
> > + related events in userspace.
> > config HAS_ITS
> > bool
> > diff --git a/xen/drivers/video/Kconfig b/xen/drivers/video/Kconfig
> > index 52e8ce6..26daf9a 100644
> > --- a/xen/drivers/video/Kconfig
> > +++ b/xen/drivers/video/Kconfig
> > @@ -13,4 +13,10 @@ config VGA
> > If unsure, say Y.
> > config HAS_ARM_HDLCD
>
> To be honest I would just rip off the driver. I doubt anybody has been using
> it for the past 5 years and only targets vexpress.
It is true, the only reason for keeping it would be as a reference
example, but I don't know if it is worth having it in the tree just for
that. I'll remove it completely, unless you tell me otherwise.
> > - bool
> > + bool "ARM HDLCD driver"
> > + default n
> > + select VIDEO
> > + ---help---
> > + Enable Xen video output to ARM HDLCD graphic controllers.
> > +
> > + if unsure, say N.
> >
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/6] arm: make it possible to disable more kconfig options
2018-05-21 19:58 ` Stefano Stabellini
@ 2018-05-22 8:24 ` Julien Grall
2018-05-22 20:15 ` Stefano Stabellini
0 siblings, 1 reply; 50+ messages in thread
From: Julien Grall @ 2018-05-22 8:24 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel
Hi,
On 05/21/2018 08:58 PM, Stefano Stabellini wrote:
> On Thu, 19 Apr 2018, Julien Grall wrote:
>>> +
>>> +config HAS_MEM_ACCESS
>>> + bool
>>> + prompt "Memory Access and VM events"
>>> + default y
>>
>> Most of the memaccess code is not protected by HAS_MEM_ACCESS. So you are
>> going to drop just a couple of hundreds line. Not sure if it is worth it in
>> the actual state.
>
> Yes, the LOC count it is not worth it today, but I would still like to
> make it selectable because I don't want Xen to come to rely on having
> HAS_MEM_ACCESS enabled all the time. !MEM_ACCESS is a good and valid
> configuration. Also, we can go forward in making more stuff protected by
> HAS_MEM_ACCESS soon.
The common code already doesn't rely on memaccess thanks to when Arm was
not support it. While I agree that we don't want HAS_MEM_ACCESS enabled
all the time, I question the usefulness of that possibility today. What
you are going to remove is about ~150 lines of pumbling to the
userspace. That's it.
All the meat (and complexity) of memaccess is still here (~500 lines).
You can achieve the same situation with using XSM. So I don't see the
real benefits of it here.
It would be better to first guard all memaccess code and then expose the
config if we still think it is useful.
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] 50+ messages in thread
* Re: [PATCH 1/6] arm: make it possible to disable more kconfig options
2018-05-22 8:24 ` Julien Grall
@ 2018-05-22 20:15 ` Stefano Stabellini
0 siblings, 0 replies; 50+ messages in thread
From: Stefano Stabellini @ 2018-05-22 20:15 UTC (permalink / raw)
To: Julien Grall; +Cc: Stefano Stabellini, xen-devel
On Tue, 22 May 2018, Julien Grall wrote:
> Hi,
>
> On 05/21/2018 08:58 PM, Stefano Stabellini wrote:
> > On Thu, 19 Apr 2018, Julien Grall wrote:
> > > > +
> > > > +config HAS_MEM_ACCESS
> > > > + bool
> > > > + prompt "Memory Access and VM events"
> > > > + default y
> > >
> > > Most of the memaccess code is not protected by HAS_MEM_ACCESS. So you are
> > > going to drop just a couple of hundreds line. Not sure if it is worth it
> > > in
> > > the actual state.
> >
> > Yes, the LOC count it is not worth it today, but I would still like to
> > make it selectable because I don't want Xen to come to rely on having
> > HAS_MEM_ACCESS enabled all the time. !MEM_ACCESS is a good and valid
> > configuration. Also, we can go forward in making more stuff protected by
> > HAS_MEM_ACCESS soon.
>
> The common code already doesn't rely on memaccess thanks to when Arm was not
> support it. While I agree that we don't want HAS_MEM_ACCESS enabled all the
> time, I question the usefulness of that possibility today. What you are going
> to remove is about ~150 lines of pumbling to the userspace. That's it.
>
> All the meat (and complexity) of memaccess is still here (~500 lines). You can
> achieve the same situation with using XSM. So I don't see the real benefits of
> it here.
>
> It would be better to first guard all memaccess code and then expose the
> config if we still think it is useful.
I am happy to hear that you also don't want HAS_MEM_ACCESS enabled all
the time. Then, it is just a question on when and how. Given that I am
doing kconfig changes now, I prefer to do them all at once, then move to
adding more #define (which I definitely intend to do next). It is very
easy to break these patches, they don't rebase easily, especially the
HAS_MEM_ACCESS rename. This is why I would prefer to make MEM_ACCES
optional as part of this series.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH 2/6] arm: make it possible to enable/disable UART drivers
2018-04-18 22:15 [PATCH 0/6] arm: more kconfig configurability and small default configs Stefano Stabellini
2018-04-18 22:15 ` [PATCH 1/6] arm: make it possible to disable more kconfig options Stefano Stabellini
@ 2018-04-18 22:15 ` Stefano Stabellini
2018-04-19 15:42 ` Julien Grall
2018-04-18 22:15 ` [PATCH 3/6] arm: make it possible to disable the SMMU driver Stefano Stabellini
` (6 subsequent siblings)
8 siblings, 1 reply; 50+ messages in thread
From: Stefano Stabellini @ 2018-04-18 22:15 UTC (permalink / raw)
To: julien.grall; +Cc: sstabellini, 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>
---
xen/drivers/char/Kconfig | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index cc78ec3..b6fcefd 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,7 @@ config HAS_SCIF
or Renesas R-Car Gen 2/3 based board say Y.
config HAS_EHCI
- bool
+ bool "EHCI UART driver"
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] 50+ messages in thread
* Re: [PATCH 2/6] arm: make it possible to enable/disable UART drivers
2018-04-18 22:15 ` [PATCH 2/6] arm: make it possible to enable/disable UART drivers Stefano Stabellini
@ 2018-04-19 15:42 ` Julien Grall
2018-05-21 20:18 ` Stefano Stabellini
0 siblings, 1 reply; 50+ messages in thread
From: Julien Grall @ 2018-04-19 15:42 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Wei Liu, George Dunlap, Tim Deegan, Ian Jackson, xen-devel, Jan Beulich
Hi Stefano,
Please CC "THE REST" maintainers here.
On 18/04/18 23:15, Stefano Stabellini wrote:
> 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>
> ---
> xen/drivers/char/Kconfig | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
> index cc78ec3..b6fcefd 100644
> --- a/xen/drivers/char/Kconfig
> +++ b/xen/drivers/char/Kconfig
> @@ -1,11 +1,11 @@
> config HAS_NS16550
> - bool
> + bool "NS16550 UART driver"
It looks like to me that x86 will require this unconditionally. So
that's going to break randconfig.
> 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 am not entirely sure whether x86 require it by default.
> + 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,7 @@ config HAS_SCIF
> or Renesas R-Car Gen 2/3 based board say Y.
>
> config HAS_EHCI
> - bool
> + bool "EHCI UART driver"
Well, you are going to break at least Arm because this driver is not
meant to be working there.
Furthermore, it looks like to me that x86 will require this unconditionally.
> 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.
>
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] 50+ messages in thread
* Re: [PATCH 2/6] arm: make it possible to enable/disable UART drivers
2018-04-19 15:42 ` Julien Grall
@ 2018-05-21 20:18 ` Stefano Stabellini
2018-05-21 20:20 ` Stefano Stabellini
0 siblings, 1 reply; 50+ messages in thread
From: Stefano Stabellini @ 2018-05-21 20:18 UTC (permalink / raw)
To: Julien Grall
Cc: Stefano Stabellini, Wei Liu, George Dunlap, Ian Jackson,
Tim Deegan, xen-devel, Jan Beulich
On Thu, 19 Apr 2018, Julien Grall wrote:
> Hi Stefano,
>
> Please CC "THE REST" maintainers here.
>
> On 18/04/18 23:15, Stefano Stabellini wrote:
> > 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>
> > ---
> > xen/drivers/char/Kconfig | 16 ++++++++--------
> > 1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
> > index cc78ec3..b6fcefd 100644
> > --- a/xen/drivers/char/Kconfig
> > +++ b/xen/drivers/char/Kconfig
> > @@ -1,11 +1,11 @@
> > config HAS_NS16550
> > - bool
> > + bool "NS16550 UART driver"
>
> It looks like to me that x86 will require this unconditionally. So that's
> going to break randconfig.
Thank you, I'll fix
> > 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 am not entirely sure whether x86 require it by default.
> > + 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,7 @@ config HAS_SCIF
> > or Renesas R-Car Gen 2/3 based board say Y.
> > config HAS_EHCI
> > - bool
> > + bool "EHCI UART driver"
>
> Well, you are going to break at least Arm because this driver is not meant to
> be working there.
>
> Furthermore, it looks like to me that x86 will require this unconditionally.
I'll fix this too
> > 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.
> >
>
> 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] 50+ messages in thread
* Re: [PATCH 2/6] arm: make it possible to enable/disable UART drivers
2018-05-21 20:18 ` Stefano Stabellini
@ 2018-05-21 20:20 ` Stefano Stabellini
0 siblings, 0 replies; 50+ messages in thread
From: Stefano Stabellini @ 2018-05-21 20:20 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Wei Liu, George Dunlap, Ian Jackson, Tim Deegan, xen-devel,
Julien Grall, Jan Beulich
On Mon, 21 May 2018, Stefano Stabellini wrote:
> On Thu, 19 Apr 2018, Julien Grall wrote:
> > Hi Stefano,
> >
> > Please CC "THE REST" maintainers here.
> >
> > On 18/04/18 23:15, Stefano Stabellini wrote:
> > > 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>
> > > ---
> > > xen/drivers/char/Kconfig | 16 ++++++++--------
> > > 1 file changed, 8 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
> > > index cc78ec3..b6fcefd 100644
> > > --- a/xen/drivers/char/Kconfig
> > > +++ b/xen/drivers/char/Kconfig
> > > @@ -1,11 +1,11 @@
> > > config HAS_NS16550
> > > - bool
> > > + bool "NS16550 UART driver"
> >
> > It looks like to me that x86 will require this unconditionally. So that's
> > going to break randconfig.
>
> Thank you, I'll fix
>
>
> > > 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 am not entirely sure whether x86 require it by default.
> > > + 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,7 @@ config HAS_SCIF
> > > or Renesas R-Car Gen 2/3 based board say Y.
> > > config HAS_EHCI
> > > - bool
> > > + bool "EHCI UART driver"
> >
> > Well, you are going to break at least Arm because this driver is not meant to
> > be working there.
> >
> > Furthermore, it looks like to me that x86 will require this unconditionally.
>
> I'll fix this too
Actually x86 already select both, I just have to make HAS_EHCI depend on
x86.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH 3/6] arm: make it possible to disable the SMMU driver
2018-04-18 22:15 [PATCH 0/6] arm: more kconfig configurability and small default configs Stefano Stabellini
2018-04-18 22:15 ` [PATCH 1/6] arm: make it possible to disable more kconfig options Stefano Stabellini
2018-04-18 22:15 ` [PATCH 2/6] arm: make it possible to enable/disable UART drivers Stefano Stabellini
@ 2018-04-18 22:15 ` Stefano Stabellini
2018-04-19 7:46 ` Jan Beulich
2018-04-19 15:44 ` Julien Grall
2018-04-18 22:15 ` [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3 Stefano Stabellini
` (5 subsequent siblings)
8 siblings, 2 replies; 50+ messages in thread
From: Stefano Stabellini @ 2018-04-18 22:15 UTC (permalink / raw)
To: julien.grall; +Cc: sstabellini, jbeulich, xen-devel
Introduce a Kconfig option for the ARM SMMUv2 driver.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
CC: jbeulich@suse.com
---
xen/drivers/passthrough/Kconfig | 2 ++
xen/drivers/passthrough/arm/Kconfig | 7 +++++++
xen/drivers/passthrough/arm/Makefile | 2 +-
3 files changed, 10 insertions(+), 1 deletion(-)
create mode 100644 xen/drivers/passthrough/arm/Kconfig
diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig
index 8d90b67..2fe94fa 100644
--- a/xen/drivers/passthrough/Kconfig
+++ b/xen/drivers/passthrough/Kconfig
@@ -1,3 +1,5 @@
config HAS_PASSTHROUGH
bool
+
+source "drivers/passthrough/arm/Kconfig"
diff --git a/xen/drivers/passthrough/arm/Kconfig b/xen/drivers/passthrough/arm/Kconfig
new file mode 100644
index 0000000..98318d9
--- /dev/null
+++ b/xen/drivers/passthrough/arm/Kconfig
@@ -0,0 +1,7 @@
+
+config HAS_SMMUv2
+ bool "ARM SMMUv2 driver"
+ default y
+ depends on ARM
+ ---help---
+ Driver for the ARM SMMU version 2, a popular IOMMU by ARM.
diff --git a/xen/drivers/passthrough/arm/Makefile b/xen/drivers/passthrough/arm/Makefile
index f4cd26e..4db273a 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-$(HAS_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] 50+ messages in thread
* Re: [PATCH 3/6] arm: make it possible to disable the SMMU driver
2018-04-18 22:15 ` [PATCH 3/6] arm: make it possible to disable the SMMU driver Stefano Stabellini
@ 2018-04-19 7:46 ` Jan Beulich
2018-04-19 22:43 ` Stefano Stabellini
2018-04-19 15:44 ` Julien Grall
1 sibling, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2018-04-19 7:46 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Julien Grall, xen-devel
>>> On 19.04.18 at 00:15, <sstabellini@kernel.org> wrote:
> --- /dev/null
> +++ b/xen/drivers/passthrough/arm/Kconfig
> @@ -0,0 +1,7 @@
> +
> +config HAS_SMMUv2
> + bool "ARM SMMUv2 driver"
> + default y
> + depends on ARM
> + ---help---
> + Driver for the ARM SMMU version 2, a popular IOMMU by ARM.
This being user-visible but not dependent upon EXPERT - what's the
support status of a hypervisor built without that option? Please recall
that as a rule of thumb we try to limit the number of different
configurations people can build without setting EXPERT, such that we
don't have to go long ways to figure out what configuration was used
in case someone reports a problem. People enabling EXPERT are left
on their own anyway.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 3/6] arm: make it possible to disable the SMMU driver
2018-04-19 7:46 ` Jan Beulich
@ 2018-04-19 22:43 ` Stefano Stabellini
2018-04-20 9:41 ` Jan Beulich
2018-04-23 18:18 ` Andrii Anisov
0 siblings, 2 replies; 50+ messages in thread
From: Stefano Stabellini @ 2018-04-19 22:43 UTC (permalink / raw)
To: Jan Beulich
Cc: tim, Stefano Stabellini, wei.liu2, George.Dunlap, andrew.cooper3,
ian.jackson, xen-devel, julien.grall, jbeulich
On Thu, 19 Apr 2018, Jan Beulich wrote:
> >>> On 19.04.18 at 00:15, <sstabellini@kernel.org> wrote:
> > --- /dev/null
> > +++ b/xen/drivers/passthrough/arm/Kconfig
> > @@ -0,0 +1,7 @@
> > +
> > +config HAS_SMMUv2
> > + bool "ARM SMMUv2 driver"
> > + default y
> > + depends on ARM
> > + ---help---
> > + Driver for the ARM SMMU version 2, a popular IOMMU by ARM.
>
> This being user-visible but not dependent upon EXPERT - what's the
> support status of a hypervisor built without that option?
Let me take a step back to give you a bit of context to this work, which
will help us decide the best way forward in terms of security support. I
am CC'ing the REST maintainers as well.
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 a patch to give us the
lines of code count exactly for that purpose. For reference, one of the
selling points of ACRN is the small code size [0].
I expect kconfig options to proliferate and, generally, all-purpose
kconfigs becoming less attractive going forward. Having kconfig options
for drivers that should be security supported otherwise is inevitable.
Let's take this example: SMMUv2. The driver is decently quality, and
definitely some boards will require it. It makes sense to security
support it. However, some boards don't come with an SMMU at all, such as
Pine64, or have a different SMMU, such as the Renesas RCar. Certainly,
the smallest kconfig for Pine64/Renesas Rcar shouldn't have the SMMUv2
driver [1]. I think it makes sense to allow the SMMUv2 driver to be
disabled by users. The same argument goes for all of the UART drivers:
each board has only one type of UART, it doesn't make sense to enable
more than one in a kconfig [2].
I think it is OK *not* to security support any option that depends on
EXPERT. But I also think we should allow for options that are
user-visible *and* security supported.
What do you guys think?
[0] https://projectacrn.org/
[1] I realize I enabled the SMMUv2 in the Renesas Rcar kconfig by
mistake, I'll fix in v2.
[2] See patch #2
> Please recall that as a rule of thumb we try to limit the number of
> different configurations people can build without setting EXPERT, such
> that we don't have to go long ways to figure out what configuration
> was used in case someone reports a problem. People enabling EXPERT are
> left on their own anyway.
To address this specific concern I would like to embed the .config into
the Xen binary, so that we can go back and ask for the kconfig used to
generated Xen easily, see:
https://xenproject.atlassian.net/browse/XEN-38
I intend to come up with a patch and add it to this series.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 3/6] arm: make it possible to disable the SMMU driver
2018-04-19 22:43 ` Stefano Stabellini
@ 2018-04-20 9:41 ` Jan Beulich
2018-04-20 17:03 ` Stefano Stabellini
2018-04-23 18:18 ` Andrii Anisov
1 sibling, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2018-04-20 9:41 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Tim Deegan, Wei Liu, George Dunlap, Andrew Cooper, Ian Jackson,
xen-devel, Julien Grall
>>> On 20.04.18 at 00:43, <sstabellini@kernel.org> wrote:
> On Thu, 19 Apr 2018, Jan Beulich wrote:
>> >>> On 19.04.18 at 00:15, <sstabellini@kernel.org> wrote:
>> > --- /dev/null
>> > +++ b/xen/drivers/passthrough/arm/Kconfig
>> > @@ -0,0 +1,7 @@
>> > +
>> > +config HAS_SMMUv2
>> > + bool "ARM SMMUv2 driver"
>> > + default y
>> > + depends on ARM
>> > + ---help---
>> > + Driver for the ARM SMMU version 2, a popular IOMMU by ARM.
>>
>> This being user-visible but not dependent upon EXPERT - what's the
>> support status of a hypervisor built without that option?
>
> Let me take a step back to give you a bit of context to this work, which
> will help us decide the best way forward in terms of security support. I
> am CC'ing the REST maintainers as well.
>
> 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 a patch to give us the
> lines of code count exactly for that purpose. For reference, one of the
> selling points of ACRN is the small code size [0].
>
> I expect kconfig options to proliferate and, generally, all-purpose
> kconfigs becoming less attractive going forward. Having kconfig options
> for drivers that should be security supported otherwise is inevitable.
>
>
> Let's take this example: SMMUv2. The driver is decently quality, and
> definitely some boards will require it. It makes sense to security
> support it. However, some boards don't come with an SMMU at all, such as
> Pine64, or have a different SMMU, such as the Renesas RCar. Certainly,
> the smallest kconfig for Pine64/Renesas Rcar shouldn't have the SMMUv2
> driver [1]. I think it makes sense to allow the SMMUv2 driver to be
> disabled by users. The same argument goes for all of the UART drivers:
> each board has only one type of UART, it doesn't make sense to enable
> more than one in a kconfig [2].
>
> I think it is OK *not* to security support any option that depends on
> EXPERT. But I also think we should allow for options that are
> user-visible *and* security supported.
>
> What do you guys think?
How about a limited set of "canned" configurations which are security
supported?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 3/6] arm: make it possible to disable the SMMU driver
2018-04-20 9:41 ` Jan Beulich
@ 2018-04-20 17:03 ` Stefano Stabellini
0 siblings, 0 replies; 50+ messages in thread
From: Stefano Stabellini @ 2018-04-20 17:03 UTC (permalink / raw)
To: Jan Beulich
Cc: Tim Deegan, Stefano Stabellini, Wei Liu, George Dunlap,
Andrew Cooper, Ian Jackson, xen-devel, Julien Grall
On Fri, 20 Apr 2018, Jan Beulich wrote:
> >>> On 20.04.18 at 00:43, <sstabellini@kernel.org> wrote:
> > On Thu, 19 Apr 2018, Jan Beulich wrote:
> >> >>> On 19.04.18 at 00:15, <sstabellini@kernel.org> wrote:
> >> > --- /dev/null
> >> > +++ b/xen/drivers/passthrough/arm/Kconfig
> >> > @@ -0,0 +1,7 @@
> >> > +
> >> > +config HAS_SMMUv2
> >> > + bool "ARM SMMUv2 driver"
> >> > + default y
> >> > + depends on ARM
> >> > + ---help---
> >> > + Driver for the ARM SMMU version 2, a popular IOMMU by ARM.
> >>
> >> This being user-visible but not dependent upon EXPERT - what's the
> >> support status of a hypervisor built without that option?
> >
> > Let me take a step back to give you a bit of context to this work, which
> > will help us decide the best way forward in terms of security support. I
> > am CC'ing the REST maintainers as well.
> >
> > 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 a patch to give us the
> > lines of code count exactly for that purpose. For reference, one of the
> > selling points of ACRN is the small code size [0].
> >
> > I expect kconfig options to proliferate and, generally, all-purpose
> > kconfigs becoming less attractive going forward. Having kconfig options
> > for drivers that should be security supported otherwise is inevitable.
> >
> >
> > Let's take this example: SMMUv2. The driver is decently quality, and
> > definitely some boards will require it. It makes sense to security
> > support it. However, some boards don't come with an SMMU at all, such as
> > Pine64, or have a different SMMU, such as the Renesas RCar. Certainly,
> > the smallest kconfig for Pine64/Renesas Rcar shouldn't have the SMMUv2
> > driver [1]. I think it makes sense to allow the SMMUv2 driver to be
> > disabled by users. The same argument goes for all of the UART drivers:
> > each board has only one type of UART, it doesn't make sense to enable
> > more than one in a kconfig [2].
> >
> > I think it is OK *not* to security support any option that depends on
> > EXPERT. But I also think we should allow for options that are
> > user-visible *and* security supported.
> >
> > What do you guys think?
>
> How about a limited set of "canned" configurations which are security
> supported?
Yes, I think that is a good idea. It is a natural evolution of what we
are already doing.
As I mentioned here https://marc.info/?l=xen-devel&m=152417800326142 in
the context of testing, I think we should only keep in-tree kconfigs
that are well tested for each release. On ARM it is not obvious as the
kconfigs are board specific, so we need somebody with the hardware to
run the tests and send back results twice a year.
With this simple rule in place, I think the number of kconfigs will be
drastically reduced to only the ones for boards that are actively used
and supported.
Moreover, specifically regarding security support, most of the ARM
kconfigs will have similar and extremely small set of kconfig options.
The only differences will be in terms of drivers: UART drivers, SMMU
drivers, GIC drivers, and little else.
Today, all these drivers options are already security supported, it is
only the number of combinations that will increase. However, generally,
I don't think that different combinations of drivers (UART, SMMU, etc)
should cause any problems: even today only one driver for each kind of
devices is actually used at runtime.
In other words, provided that we have a way to embed the .config into
the binary, I think that security-supporting a limited set of "canned"
configurations shouldn't pose any additional efforts onto the security
team. Of course, if it turns out that it generates more work than we are
prepared to handle, we can always revisit this decision.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 3/6] arm: make it possible to disable the SMMU driver
2018-04-19 22:43 ` Stefano Stabellini
2018-04-20 9:41 ` Jan Beulich
@ 2018-04-23 18:18 ` Andrii Anisov
1 sibling, 0 replies; 50+ messages in thread
From: Andrii Anisov @ 2018-04-23 18:18 UTC (permalink / raw)
To: Stefano Stabellini, Jan Beulich
Cc: wei.liu2, George.Dunlap, ian.jackson, tim, xen-devel,
julien.grall, andrew.cooper3
Hello Stefano,
On 20.04.18 01:43, Stefano Stabellini wrote:
> Let's take this example: SMMUv2. The driver is decently quality, and
> definitely some boards will require it. It makes sense to security
> support it. However, some boards don't come with an SMMU at all, such as
> Pine64
I guess arm passthrough in a whole could be dropped for such platforms.
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 3/6] arm: make it possible to disable the SMMU driver
2018-04-18 22:15 ` [PATCH 3/6] arm: make it possible to disable the SMMU driver Stefano Stabellini
2018-04-19 7:46 ` Jan Beulich
@ 2018-04-19 15:44 ` Julien Grall
2018-04-19 15:46 ` Julien Grall
2018-04-20 9:39 ` Jan Beulich
1 sibling, 2 replies; 50+ messages in thread
From: Julien Grall @ 2018-04-19 15:44 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: jbeulich, xen-devel
Hi,
On 18/04/18 23:15, Stefano Stabellini wrote:
> Introduce a Kconfig option for the ARM SMMUv2 driver.
The driver is handling both SMMUv1 and SMMUv2.
>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> CC: jbeulich@suse.com
> ---
> xen/drivers/passthrough/Kconfig | 2 ++
> xen/drivers/passthrough/arm/Kconfig | 7 +++++++
> xen/drivers/passthrough/arm/Makefile | 2 +-
> 3 files changed, 10 insertions(+), 1 deletion(-)
> create mode 100644 xen/drivers/passthrough/arm/Kconfig
>
> diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig
> index 8d90b67..2fe94fa 100644
> --- a/xen/drivers/passthrough/Kconfig
> +++ b/xen/drivers/passthrough/Kconfig
> @@ -1,3 +1,5 @@
>
> config HAS_PASSTHROUGH
> bool
> +
> +source "drivers/passthrough/arm/Kconfig"
Can't we load arm/Kconfig only when arm is selected? This would avoid
weird option on x86.
> diff --git a/xen/drivers/passthrough/arm/Kconfig b/xen/drivers/passthrough/arm/Kconfig
> new file mode 100644
> index 0000000..98318d9
> --- /dev/null
> +++ b/xen/drivers/passthrough/arm/Kconfig
> @@ -0,0 +1,7 @@
> +
> +config HAS_SMMUv2
> + bool "ARM SMMUv2 driver"
> + default y
> + depends on ARM
> + ---help---
> + Driver for the ARM SMMU version 2, a popular IOMMU by ARM.
> diff --git a/xen/drivers/passthrough/arm/Makefile b/xen/drivers/passthrough/arm/Makefile
> index f4cd26e..4db273a 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-$(HAS_SMMUv2) += smmu.o
>
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] 50+ messages in thread
* Re: [PATCH 3/6] arm: make it possible to disable the SMMU driver
2018-04-19 15:44 ` Julien Grall
@ 2018-04-19 15:46 ` Julien Grall
2018-04-20 9:39 ` Jan Beulich
1 sibling, 0 replies; 50+ messages in thread
From: Julien Grall @ 2018-04-19 15:46 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: jbeulich, xen-devel
On 19/04/18 16:44, Julien Grall wrote:
> Hi,
>
> On 18/04/18 23:15, Stefano Stabellini wrote:
>> Introduce a Kconfig option for the ARM SMMUv2 driver.
>
> The driver is handling both SMMUv1 and SMMUv2.
I forgot to mention that by disabling the driver, you are going to
end-up giving the SMMU to Dom0. I don't think we want that to happen.
So you need to find a way to blacklist all the SMMUs.
>
>>
>> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
>> CC: jbeulich@suse.com
>> ---
>> xen/drivers/passthrough/Kconfig | 2 ++
>> xen/drivers/passthrough/arm/Kconfig | 7 +++++++
>> xen/drivers/passthrough/arm/Makefile | 2 +-
>> 3 files changed, 10 insertions(+), 1 deletion(-)
>> create mode 100644 xen/drivers/passthrough/arm/Kconfig
>>
>> diff --git a/xen/drivers/passthrough/Kconfig
>> b/xen/drivers/passthrough/Kconfig
>> index 8d90b67..2fe94fa 100644
>> --- a/xen/drivers/passthrough/Kconfig
>> +++ b/xen/drivers/passthrough/Kconfig
>> @@ -1,3 +1,5 @@
>> config HAS_PASSTHROUGH
>> bool
>> +
>> +source "drivers/passthrough/arm/Kconfig"
>
> Can't we load arm/Kconfig only when arm is selected? This would avoid
> weird option on x86.
>
>> diff --git a/xen/drivers/passthrough/arm/Kconfig
>> b/xen/drivers/passthrough/arm/Kconfig
>> new file mode 100644
>> index 0000000..98318d9
>> --- /dev/null
>> +++ b/xen/drivers/passthrough/arm/Kconfig
>> @@ -0,0 +1,7 @@
>> +
>> +config HAS_SMMUv2
>> + bool "ARM SMMUv2 driver"
>> + default y
>> + depends on ARM
>> + ---help---
>> + Driver for the ARM SMMU version 2, a popular IOMMU by ARM.
>> diff --git a/xen/drivers/passthrough/arm/Makefile
>> b/xen/drivers/passthrough/arm/Makefile
>> index f4cd26e..4db273a 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-$(HAS_SMMUv2) += smmu.o
>>
>
> 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] 50+ messages in thread
* Re: [PATCH 3/6] arm: make it possible to disable the SMMU driver
2018-04-19 15:44 ` Julien Grall
2018-04-19 15:46 ` Julien Grall
@ 2018-04-20 9:39 ` Jan Beulich
2018-04-24 8:57 ` Julien Grall
1 sibling, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2018-04-20 9:39 UTC (permalink / raw)
To: Julien Grall, Stefano Stabellini; +Cc: xen-devel
>>> On 19.04.18 at 17:44, <julien.grall@arm.com> wrote:
> On 18/04/18 23:15, Stefano Stabellini wrote:
>> --- a/xen/drivers/passthrough/Kconfig
>> +++ b/xen/drivers/passthrough/Kconfig
>> @@ -1,3 +1,5 @@
>>
>> config HAS_PASSTHROUGH
>> bool
>> +
>> +source "drivers/passthrough/arm/Kconfig"
>
> Can't we load arm/Kconfig only when arm is selected? This would avoid
> weird option on x86.
How would those options appear for x86, given ...
>> --- /dev/null
>> +++ b/xen/drivers/passthrough/arm/Kconfig
>> @@ -0,0 +1,7 @@
>> +
>> +config HAS_SMMUv2
>> + bool "ARM SMMUv2 driver"
>> + default y
>> + depends on ARM
... this "depends on"? Of course if more options are going to appear here,
wrapping the whole file in "if ARM" would be useful anyway, even if only
to limit redundancy.
Otoh, as voiced before in a different context, I'm not convinced we want
such single-option Kconfig files, i.e. in the case here the option may better
go directly into xen/drivers/passthrough/Kconfig. Splitting files when they
grow too large is an option anyway.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 3/6] arm: make it possible to disable the SMMU driver
2018-04-20 9:39 ` Jan Beulich
@ 2018-04-24 8:57 ` Julien Grall
2018-05-21 20:35 ` Stefano Stabellini
0 siblings, 1 reply; 50+ messages in thread
From: Julien Grall @ 2018-04-24 8:57 UTC (permalink / raw)
To: Jan Beulich, Stefano Stabellini; +Cc: xen-devel
On 04/20/2018 10:39 AM, Jan Beulich wrote:
>>>> On 19.04.18 at 17:44, <julien.grall@arm.com> wrote:
>> On 18/04/18 23:15, Stefano Stabellini wrote:
>>> --- a/xen/drivers/passthrough/Kconfig
>>> +++ b/xen/drivers/passthrough/Kconfig
>>> @@ -1,3 +1,5 @@
>>>
>>> config HAS_PASSTHROUGH
>>> bool
>>> +
>>> +source "drivers/passthrough/arm/Kconfig"
>>
>> Can't we load arm/Kconfig only when arm is selected? This would avoid
>> weird option on x86.
>
> How would those options appear for x86, given ...
>
>>> --- /dev/null
>>> +++ b/xen/drivers/passthrough/arm/Kconfig
>>> @@ -0,0 +1,7 @@
>>> +
>>> +config HAS_SMMUv2
>>> + bool "ARM SMMUv2 driver"
>>> + default y
>>> + depends on ARM
>
> ... this "depends on"? Of course if more options are going to appear here,
> wrapping the whole file in "if ARM" would be useful anyway, even if only
> to limit redundancy.
It will appear when you search for it in the menuconfig. This will look
quite weird for x86.
>
> Otoh, as voiced before in a different context, I'm not convinced we want
> such single-option Kconfig files, i.e. in the case here the option may better
> go directly into xen/drivers/passthrough/Kconfig. Splitting files when they
> grow too large is an option anyway.
I would be ok with that.
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] 50+ messages in thread
* Re: [PATCH 3/6] arm: make it possible to disable the SMMU driver
2018-04-24 8:57 ` Julien Grall
@ 2018-05-21 20:35 ` Stefano Stabellini
2018-05-22 5:37 ` Jan Beulich
0 siblings, 1 reply; 50+ messages in thread
From: Stefano Stabellini @ 2018-05-21 20:35 UTC (permalink / raw)
To: Julien Grall; +Cc: Stefano Stabellini, Jan Beulich, xen-devel
On Tue, 24 Apr 2018, Julien Grall wrote:
> On 04/20/2018 10:39 AM, Jan Beulich wrote:
> > > > > On 19.04.18 at 17:44, <julien.grall@arm.com> wrote:
> > > On 18/04/18 23:15, Stefano Stabellini wrote:
> > > > --- a/xen/drivers/passthrough/Kconfig
> > > > +++ b/xen/drivers/passthrough/Kconfig
> > > > @@ -1,3 +1,5 @@
> > > > config HAS_PASSTHROUGH
> > > > bool
> > > > +
> > > > +source "drivers/passthrough/arm/Kconfig"
> > >
> > > Can't we load arm/Kconfig only when arm is selected? This would avoid
> > > weird option on x86.
> >
> > How would those options appear for x86, given ...
> >
> > > > --- /dev/null
> > > > +++ b/xen/drivers/passthrough/arm/Kconfig
> > > > @@ -0,0 +1,7 @@
> > > > +
> > > > +config HAS_SMMUv2
> > > > + bool "ARM SMMUv2 driver"
> > > > + default y
> > > > + depends on ARM
> >
> > ... this "depends on"? Of course if more options are going to appear here,
> > wrapping the whole file in "if ARM" would be useful anyway, even if only
> > to limit redundancy.
Sorry, I think I am misunderstanding your suggestion. If you are
suggesting:
#if ARM
config HAS_SMMUv2
bool "ARM SMMUv2 driver"
default y
depends on ARM
#endif
then, this won't work because we are not running the kconfig files
through the preprocessor.
> It will appear when you search for it in the menuconfig. This will look quite
> weird for x86.
Is this a problem? If so, how do we want to fix it? I am OK with
anything, but if it was up to me I would leave it as is (HAS_SMMUv2
comes up on x86 searches on the menu).
> > Otoh, as voiced before in a different context, I'm not convinced we want
> > such single-option Kconfig files, i.e. in the case here the option may
> > better
> > go directly into xen/drivers/passthrough/Kconfig. Splitting files when they
> > grow too large is an option anyway.
>
> I would be ok with that.
I'll make the change
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 3/6] arm: make it possible to disable the SMMU driver
2018-05-21 20:35 ` Stefano Stabellini
@ 2018-05-22 5:37 ` Jan Beulich
0 siblings, 0 replies; 50+ messages in thread
From: Jan Beulich @ 2018-05-22 5:37 UTC (permalink / raw)
To: sstabellini; +Cc: julien.grall, xen-devel
>>> Stefano Stabellini <sstabellini@kernel.org> 05/21/18 10:35 PM >>>
>On Tue, 24 Apr 2018, Julien Grall wrote:
>> On 04/20/2018 10:39 AM, Jan Beulich wrote:
>> > > > > On 19.04.18 at 17:44, <julien.grall@arm.com> wrote:
>> > > On 18/04/18 23:15, Stefano Stabellini wrote:
>> > > > --- a/xen/drivers/passthrough/Kconfig
>> > > > +++ b/xen/drivers/passthrough/Kconfig
>> > > > @@ -1,3 +1,5 @@
>> > > > config HAS_PASSTHROUGH
>> > > > bool
>> > > > +
>> > > > +source "drivers/passthrough/arm/Kconfig"
>> > >
>> > > Can't we load arm/Kconfig only when arm is selected? This would avoid
>> > > weird option on x86.
>> >
>> > How would those options appear for x86, given ...
>> >
>> > > > --- /dev/null
>> > > > +++ b/xen/drivers/passthrough/arm/Kconfig
>> > > > @@ -0,0 +1,7 @@
>> > > > +
>> > > > +config HAS_SMMUv2
>> > > > + bool "ARM SMMUv2 driver"
>> > > > + default y
>> > > > + depends on ARM
>> >
>> > ... this "depends on"? Of course if more options are going to appear here,
>> > wrapping the whole file in "if ARM" would be useful anyway, even if only
>> > to limit redundancy.
>
>Sorry, I think I am misunderstanding your suggestion. If you are
>suggesting:
>
>#if ARM
>config HAS_SMMUv2
>bool "ARM SMMUv2 driver"
>default y
>depends on ARM
>#endif
>
>then, this won't work because we are not running the kconfig files
>through the preprocessor.
if ARM
config HAS_SMMUv2
bool "ARM SMMUv2 driver"
default y
endif
The "if" basically adds a respective "depends on" for all enclosed options.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3
2018-04-18 22:15 [PATCH 0/6] arm: more kconfig configurability and small default configs Stefano Stabellini
` (2 preceding siblings ...)
2018-04-18 22:15 ` [PATCH 3/6] arm: make it possible to disable the SMMU driver Stefano Stabellini
@ 2018-04-18 22:15 ` Stefano Stabellini
2018-04-19 8:06 ` Andrew Cooper
2018-04-23 18:30 ` Andrii Anisov
2018-04-18 22:15 ` [PATCH 5/6] arm: add a small kconfig for qemu-system-aarch64 Stefano Stabellini
` (4 subsequent siblings)
8 siblings, 2 replies; 50+ messages in thread
From: Stefano Stabellini @ 2018-04-18 22:15 UTC (permalink / raw)
To: julien.grall; +Cc: artem_mygaiev, sstabellini, volodymyr_babchuk, xen-devel
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.
---
xen/arch/arm/configs/renesas.config | 80 +++++++++++++++++++++++++++++++++++++
1 file changed, 80 insertions(+)
create mode 100644 xen/arch/arm/configs/renesas.config
diff --git a/xen/arch/arm/configs/renesas.config b/xen/arch/arm/configs/renesas.config
new file mode 100644
index 0000000..7ad3f1c
--- /dev/null
+++ b/xen/arch/arm/configs/renesas.config
@@ -0,0 +1,80 @@
+#
+# Automatically generated file; DO NOT EDIT.
+# Xen/arm 4.11-unstable Configuration
+#
+CONFIG_64BIT=y
+CONFIG_ARM_64=y
+CONFIG_ARM=y
+CONFIG_ARCH_DEFCONFIG="arch/arm/configs/arm64_defconfig"
+
+#
+# Architecture Features
+#
+CONFIG_NR_CPUS=8
+# CONFIG_ACPI is not set
+# CONFIG_HAS_GICV3 is not set
+# CONFIG_HAS_MEM_ACCESS is not set
+# CONFIG_NEW_VGIC is not set
+# CONFIG_SBSA_VUART_CONSOLE is not set
+
+#
+# ARM errata workaround via the alternative framework
+#
+CONFIG_ARM64_ERRATUM_827319=y
+CONFIG_ARM64_ERRATUM_824069=y
+CONFIG_ARM64_ERRATUM_819472=y
+CONFIG_ARM64_ERRATUM_832075=y
+CONFIG_ARM64_ERRATUM_834220=y
+CONFIG_HARDEN_BRANCH_PREDICTOR=y
+CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR=y
+
+#
+# Common Features
+#
+CONFIG_HAS_ALTERNATIVE=y
+CONFIG_HAS_DEVICE_TREE=y
+CONFIG_HAS_PDX=y
+# CONFIG_TMEM is not set
+# CONFIG_XSM is not set
+
+#
+# Schedulers
+#
+CONFIG_SCHED_CREDIT=y
+# CONFIG_SCHED_CREDIT2 is not set
+# CONFIG_SCHED_RTDS is not set
+# CONFIG_SCHED_ARINC653 is not set
+CONFIG_SCHED_NULL=y
+# CONFIG_SCHED_CREDIT_DEFAULT is not set
+CONFIG_SCHED_NULL_DEFAULT=y
+CONFIG_SCHED_DEFAULT="null"
+# CONFIG_LIVEPATCH is not set
+# CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set
+CONFIG_CMDLINE=""
+
+#
+# Device Drivers
+#
+# CONFIG_HAS_NS16550 is not set
+# CONFIG_HAS_CADENCE_UART is not set
+# CONFIG_HAS_MVEBU is not set
+# CONFIG_HAS_PL011 is not set
+CONFIG_HAS_SCIF=y
+# CONFIG_HAS_EHCI is not set
+CONFIG_HAS_PASSTHROUGH=y
+CONFIG_HAS_SMMUv2=y
+# CONFIG_VIDEO is not set
+# CONFIG_HAS_ARM_HDLCD is not set
+CONFIG_DEFCONFIG_LIST="$ARCH_DEFCONFIG"
+
+#
+# Debugging Options
+#
+# CONFIG_DEBUG is not set
+# CONFIG_FRAME_POINTER is not set
+# CONFIG_COVERAGE is not set
+# CONFIG_LOCK_PROFILE is not set
+# CONFIG_PERF_COUNTERS is not set
+# CONFIG_VERBOSE_DEBUG is not set
+# CONFIG_DEVICE_TREE_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] 50+ messages in thread
* Re: [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3
2018-04-18 22:15 ` [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3 Stefano Stabellini
@ 2018-04-19 8:06 ` Andrew Cooper
2018-04-19 8:53 ` Juergen Gross
2018-04-23 18:30 ` Andrii Anisov
1 sibling, 1 reply; 50+ messages in thread
From: Andrew Cooper @ 2018-04-19 8:06 UTC (permalink / raw)
To: Stefano Stabellini, julien.grall
Cc: artem_mygaiev, volodymyr_babchuk, xen-devel
On 18/04/2018 23:15, Stefano Stabellini wrote:
> xen/arch/arm/configs/renesas.config | 80 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 80 insertions(+)
> create mode 100644 xen/arch/arm/configs/renesas.config
>
> diff --git a/xen/arch/arm/configs/renesas.config b/xen/arch/arm/configs/renesas.config
> new file mode 100644
> index 0000000..7ad3f1c
> --- /dev/null
> +++ b/xen/arch/arm/configs/renesas.config
> @@ -0,0 +1,80 @@
> +#
> +# Automatically generated file; DO NOT EDIT.
> +# Xen/arm 4.11-unstable Configuration
> +#
This is now the second Kconfig file we've got added into the tree. As
with the PV-shim config, keeping it up to date is going to be a little
tricky.
I think we either need a script to keep all of the embedded configs up
to date, or switch to a model (similar to the travis randconfig target)
where it becomes a `make defaultconfig` with certain specific options
forced one way or another (similar to `make {tiny,kvm,xen}config` in
Linux). The latter means that we only store the specific delta
applicable for purpose, and it will probably change less frequently.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3
2018-04-19 8:06 ` Andrew Cooper
@ 2018-04-19 8:53 ` Juergen Gross
2018-04-19 23:00 ` Stefano Stabellini
0 siblings, 1 reply; 50+ messages in thread
From: Juergen Gross @ 2018-04-19 8:53 UTC (permalink / raw)
To: Andrew Cooper, Stefano Stabellini, julien.grall
Cc: artem_mygaiev, volodymyr_babchuk, xen-devel
On 19/04/18 10:06, Andrew Cooper wrote:
> On 18/04/2018 23:15, Stefano Stabellini wrote:
>> xen/arch/arm/configs/renesas.config | 80 +++++++++++++++++++++++++++++++++++++
>> 1 file changed, 80 insertions(+)
>> create mode 100644 xen/arch/arm/configs/renesas.config
>>
>> diff --git a/xen/arch/arm/configs/renesas.config b/xen/arch/arm/configs/renesas.config
>> new file mode 100644
>> index 0000000..7ad3f1c
>> --- /dev/null
>> +++ b/xen/arch/arm/configs/renesas.config
>> @@ -0,0 +1,80 @@
>> +#
>> +# Automatically generated file; DO NOT EDIT.
>> +# Xen/arm 4.11-unstable Configuration
>> +#
>
> This is now the second Kconfig file we've got added into the tree. As
> with the PV-shim config, keeping it up to date is going to be a little
> tricky.
>
> I think we either need a script to keep all of the embedded configs up
> to date, or switch to a model (similar to the travis randconfig target)
> where it becomes a `make defaultconfig` with certain specific options
> forced one way or another (similar to `make {tiny,kvm,xen}config` in
> Linux). The latter means that we only store the specific delta
> applicable for purpose, and it will probably change less frequently.
I think the easiest way would be to have a config file with only the
required non-default options being specified and then run
"make olddefconfig" against that (or better: a copy of that in order
to avoid modifying a source from git).
I'm just writing a patch to do that for the shim config as it is nasty
to remove shim.config from my patches in case it has been modified by
the build (again) and STGit has picked it up.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3
2018-04-19 8:53 ` Juergen Gross
@ 2018-04-19 23:00 ` Stefano Stabellini
2018-04-20 4:39 ` Juergen Gross
0 siblings, 1 reply; 50+ messages in thread
From: Stefano Stabellini @ 2018-04-19 23:00 UTC (permalink / raw)
To: Juergen Gross
Cc: artem_mygaiev, Stefano Stabellini, Andrew Cooper, xen-devel,
julien.grall, volodymyr_babchuk
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2069 bytes --]
On Thu, 19 Apr 2018, Juergen Gross wrote:
> On 19/04/18 10:06, Andrew Cooper wrote:
> > On 18/04/2018 23:15, Stefano Stabellini wrote:
> >> xen/arch/arm/configs/renesas.config | 80 +++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 80 insertions(+)
> >> create mode 100644 xen/arch/arm/configs/renesas.config
> >>
> >> diff --git a/xen/arch/arm/configs/renesas.config b/xen/arch/arm/configs/renesas.config
> >> new file mode 100644
> >> index 0000000..7ad3f1c
> >> --- /dev/null
> >> +++ b/xen/arch/arm/configs/renesas.config
> >> @@ -0,0 +1,80 @@
> >> +#
> >> +# Automatically generated file; DO NOT EDIT.
> >> +# Xen/arm 4.11-unstable Configuration
> >> +#
> >
> > This is now the second Kconfig file we've got added into the tree. As
> > with the PV-shim config, keeping it up to date is going to be a little
> > tricky.
> >
> > I think we either need a script to keep all of the embedded configs up
> > to date, or switch to a model (similar to the travis randconfig target)
> > where it becomes a `make defaultconfig` with certain specific options
> > forced one way or another (similar to `make {tiny,kvm,xen}config` in
> > Linux). The latter means that we only store the specific delta
> > applicable for purpose, and it will probably change less frequently.
>
> I think the easiest way would be to have a config file with only the
> required non-default options being specified and then run
> "make olddefconfig" against that (or better: a copy of that in order
> to avoid modifying a source from git).
>
> I'm just writing a patch to do that for the shim config as it is nasty
> to remove shim.config from my patches in case it has been modified by
> the build (again) and STGit has picked it up.
Given that the goal of this kconfig is to provide the smallest possible
kconfig for a given board, I think that your suggestion wouldn't end up
improving things much in this case because most options will have to be
specified as "disabled", otherwise "make olddefconfig" would end up
enabling some of them by default, which is not what we want.
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3
2018-04-19 23:00 ` Stefano Stabellini
@ 2018-04-20 4:39 ` Juergen Gross
2018-04-20 16:39 ` Stefano Stabellini
0 siblings, 1 reply; 50+ messages in thread
From: Juergen Gross @ 2018-04-20 4:39 UTC (permalink / raw)
To: Stefano Stabellini
Cc: artem_mygaiev, Andrew Cooper, julien.grall, volodymyr_babchuk, xen-devel
On 20/04/18 01:00, Stefano Stabellini wrote:
> On Thu, 19 Apr 2018, Juergen Gross wrote:
>> On 19/04/18 10:06, Andrew Cooper wrote:
>>> On 18/04/2018 23:15, Stefano Stabellini wrote:
>>>> xen/arch/arm/configs/renesas.config | 80 +++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 80 insertions(+)
>>>> create mode 100644 xen/arch/arm/configs/renesas.config
>>>>
>>>> diff --git a/xen/arch/arm/configs/renesas.config b/xen/arch/arm/configs/renesas.config
>>>> new file mode 100644
>>>> index 0000000..7ad3f1c
>>>> --- /dev/null
>>>> +++ b/xen/arch/arm/configs/renesas.config
>>>> @@ -0,0 +1,80 @@
>>>> +#
>>>> +# Automatically generated file; DO NOT EDIT.
>>>> +# Xen/arm 4.11-unstable Configuration
>>>> +#
>>>
>>> This is now the second Kconfig file we've got added into the tree. As
>>> with the PV-shim config, keeping it up to date is going to be a little
>>> tricky.
>>>
>>> I think we either need a script to keep all of the embedded configs up
>>> to date, or switch to a model (similar to the travis randconfig target)
>>> where it becomes a `make defaultconfig` with certain specific options
>>> forced one way or another (similar to `make {tiny,kvm,xen}config` in
>>> Linux). The latter means that we only store the specific delta
>>> applicable for purpose, and it will probably change less frequently.
>>
>> I think the easiest way would be to have a config file with only the
>> required non-default options being specified and then run
>> "make olddefconfig" against that (or better: a copy of that in order
>> to avoid modifying a source from git).
>>
>> I'm just writing a patch to do that for the shim config as it is nasty
>> to remove shim.config from my patches in case it has been modified by
>> the build (again) and STGit has picked it up.
>
> Given that the goal of this kconfig is to provide the smallest possible
> kconfig for a given board, I think that your suggestion wouldn't end up
> improving things much in this case because most options will have to be
> specified as "disabled", otherwise "make olddefconfig" would end up
> enabling some of them by default, which is not what we want.
>
What's the problem with this?
In case you really do want a config with many non-default settings
you'll have to specify them. So just do it and it's fine.
The alternative would be to specify _all_ entries. I don't see why
this would be better.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3
2018-04-20 4:39 ` Juergen Gross
@ 2018-04-20 16:39 ` Stefano Stabellini
0 siblings, 0 replies; 50+ messages in thread
From: Stefano Stabellini @ 2018-04-20 16:39 UTC (permalink / raw)
To: Juergen Gross
Cc: artem_mygaiev, Stefano Stabellini, Andrew Cooper, xen-devel,
julien.grall, volodymyr_babchuk
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2557 bytes --]
On Fri, 20 Apr 2018, Juergen Gross wrote:
> On 20/04/18 01:00, Stefano Stabellini wrote:
> > On Thu, 19 Apr 2018, Juergen Gross wrote:
> >> On 19/04/18 10:06, Andrew Cooper wrote:
> >>> On 18/04/2018 23:15, Stefano Stabellini wrote:
> >>>> xen/arch/arm/configs/renesas.config | 80 +++++++++++++++++++++++++++++++++++++
> >>>> 1 file changed, 80 insertions(+)
> >>>> create mode 100644 xen/arch/arm/configs/renesas.config
> >>>>
> >>>> diff --git a/xen/arch/arm/configs/renesas.config b/xen/arch/arm/configs/renesas.config
> >>>> new file mode 100644
> >>>> index 0000000..7ad3f1c
> >>>> --- /dev/null
> >>>> +++ b/xen/arch/arm/configs/renesas.config
> >>>> @@ -0,0 +1,80 @@
> >>>> +#
> >>>> +# Automatically generated file; DO NOT EDIT.
> >>>> +# Xen/arm 4.11-unstable Configuration
> >>>> +#
> >>>
> >>> This is now the second Kconfig file we've got added into the tree. As
> >>> with the PV-shim config, keeping it up to date is going to be a little
> >>> tricky.
> >>>
> >>> I think we either need a script to keep all of the embedded configs up
> >>> to date, or switch to a model (similar to the travis randconfig target)
> >>> where it becomes a `make defaultconfig` with certain specific options
> >>> forced one way or another (similar to `make {tiny,kvm,xen}config` in
> >>> Linux). The latter means that we only store the specific delta
> >>> applicable for purpose, and it will probably change less frequently.
> >>
> >> I think the easiest way would be to have a config file with only the
> >> required non-default options being specified and then run
> >> "make olddefconfig" against that (or better: a copy of that in order
> >> to avoid modifying a source from git).
> >>
> >> I'm just writing a patch to do that for the shim config as it is nasty
> >> to remove shim.config from my patches in case it has been modified by
> >> the build (again) and STGit has picked it up.
> >
> > Given that the goal of this kconfig is to provide the smallest possible
> > kconfig for a given board, I think that your suggestion wouldn't end up
> > improving things much in this case because most options will have to be
> > specified as "disabled", otherwise "make olddefconfig" would end up
> > enabling some of them by default, which is not what we want.
> >
>
> What's the problem with this?
>
> In case you really do want a config with many non-default settings
> you'll have to specify them. So just do it and it's fine.
>
> The alternative would be to specify _all_ entries. I don't see why
> this would be better.
Yes, you are right :-)
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3
2018-04-18 22:15 ` [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3 Stefano Stabellini
2018-04-19 8:06 ` Andrew Cooper
@ 2018-04-23 18:30 ` Andrii Anisov
2018-04-24 9:01 ` Julien Grall
1 sibling, 1 reply; 50+ messages in thread
From: Andrii Anisov @ 2018-04-23 18:30 UTC (permalink / raw)
To: Stefano Stabellini, julien.grall
Cc: artem_mygaiev, volodymyr_babchuk, xen-devel
Hello Stefano,
If we stick with platform specific configuration file:
On 19.04.18 01:15, 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.
>
> 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!
I will test it once we are aligned with it.
> Also, I am not sure whether some of the errata workarounds can be
> disabled on the RCar.
> ---
> xen/arch/arm/configs/renesas.config | 80 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 80 insertions(+)
> create mode 100644 xen/arch/arm/configs/renesas.config
>
> diff --git a/xen/arch/arm/configs/renesas.config b/xen/arch/arm/configs/renesas.config
Better name it rcar3.config. XEN still supports Renesas R-Car Gen2 which
is quite different (at least 32-bit).
> new file mode 100644
> index 0000000..7ad3f1c
> --- /dev/null
> +++ b/xen/arch/arm/configs/renesas.config
> @@ -0,0 +1,80 @@
> +#
> +# Automatically generated file; DO NOT EDIT.
> +# Xen/arm 4.11-unstable Configuration
> +#
> +CONFIG_64BIT=y
> +CONFIG_ARM_64=y
> +CONFIG_ARM=y
> +CONFIG_ARCH_DEFCONFIG="arch/arm/configs/arm64_defconfig"
> +
> +#
> +# Architecture Features
> +#
> +CONFIG_NR_CPUS=8
> +# CONFIG_ACPI is not set
> +# CONFIG_HAS_GICV3 is not set
> +# CONFIG_HAS_MEM_ACCESS is not set
> +# CONFIG_NEW_VGIC is not set
> +# CONFIG_SBSA_VUART_CONSOLE is not set
> +
> +#
> +# ARM errata workaround via the alternative framework
> +#
> +CONFIG_ARM64_ERRATUM_827319=y
> +CONFIG_ARM64_ERRATUM_824069=y
> +CONFIG_ARM64_ERRATUM_819472=y
> +CONFIG_ARM64_ERRATUM_832075=y
> +CONFIG_ARM64_ERRATUM_834220=y
> +CONFIG_HARDEN_BRANCH_PREDICTOR=y
> +CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR=y
> +
> +#
> +# Common Features
> +#
> +CONFIG_HAS_ALTERNATIVE=y
> +CONFIG_HAS_DEVICE_TREE=y
> +CONFIG_HAS_PDX=y
> +# CONFIG_TMEM is not set
> +# CONFIG_XSM is not set
> +
> +#
> +# Schedulers
> +#
> +CONFIG_SCHED_CREDIT=y
> +# CONFIG_SCHED_CREDIT2 is not set
> +# CONFIG_SCHED_RTDS is not set
> +# CONFIG_SCHED_ARINC653 is not set
> +CONFIG_SCHED_NULL=y
> +# CONFIG_SCHED_CREDIT_DEFAULT is not set
> +CONFIG_SCHED_NULL_DEFAULT=y
> +CONFIG_SCHED_DEFAULT="null"
> +# CONFIG_LIVEPATCH is not set
> +# CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set
> +CONFIG_CMDLINE=""
> +
> +#
> +# Device Drivers
> +#
> +# CONFIG_HAS_NS16550 is not set
> +# CONFIG_HAS_CADENCE_UART is not set
> +# CONFIG_HAS_MVEBU is not set
> +# CONFIG_HAS_PL011 is not set
> +CONFIG_HAS_SCIF=y
> +# CONFIG_HAS_EHCI is not set
> +CONFIG_HAS_PASSTHROUGH=y
IMHO, no passthrough support until IPMMU driver upstreamed.
> +CONFIG_HAS_SMMUv2=y
> +# CONFIG_VIDEO is not set
> +# CONFIG_HAS_ARM_HDLCD is not set
> +CONFIG_DEFCONFIG_LIST="$ARCH_DEFCONFIG"
> +
> +#
> +# Debugging Options
> +#
> +# CONFIG_DEBUG is not set
> +# CONFIG_FRAME_POINTER is not set
> +# CONFIG_COVERAGE is not set
> +# CONFIG_LOCK_PROFILE is not set
> +# CONFIG_PERF_COUNTERS is not set
> +# CONFIG_VERBOSE_DEBUG is not set
> +# CONFIG_DEVICE_TREE_DEBUG is not set
> +# CONFIG_SCRUB_DEBUG is not set
But I would rather embed platform support into Kconfigs. Specifying in a
configuration file something like CONFIG_RCAR3 and software entities
like schedulers, livepatching, debug, etc.
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3
2018-04-23 18:30 ` Andrii Anisov
@ 2018-04-24 9:01 ` Julien Grall
2018-04-24 9:52 ` Andrii Anisov
0 siblings, 1 reply; 50+ messages in thread
From: Julien Grall @ 2018-04-24 9:01 UTC (permalink / raw)
To: Andrii Anisov, Stefano Stabellini
Cc: artem_mygaiev, volodymyr_babchuk, xen-devel
Hi,
On 04/23/2018 07:30 PM, Andrii Anisov wrote:
> On 19.04.18 01:15, Stefano Stabellini wrote:
>> +#
>> +# Device Drivers
>> +#
>> +# CONFIG_HAS_NS16550 is not set
>> +# CONFIG_HAS_CADENCE_UART is not set
>> +# CONFIG_HAS_MVEBU is not set
>> +# CONFIG_HAS_PL011 is not set
>> +CONFIG_HAS_SCIF=y
>> +# CONFIG_HAS_EHCI is not set
>> +CONFIG_HAS_PASSTHROUGH=y
> IMHO, no passthrough support until IPMMU driver upstreamed.
You can't unselect HAS_PASSTHROUGH support. Given that you are going to
have passthrough in the future, I don't much see the point to try to
allow that option to be disabled.
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] 50+ messages in thread
* Re: [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3
2018-04-24 9:01 ` Julien Grall
@ 2018-04-24 9:52 ` Andrii Anisov
2018-04-24 10:06 ` Julien Grall
0 siblings, 1 reply; 50+ messages in thread
From: Andrii Anisov @ 2018-04-24 9:52 UTC (permalink / raw)
To: Julien Grall, Stefano Stabellini
Cc: artem_mygaiev, volodymyr_babchuk, xen-devel
Hello Julien,
On 24.04.18 12:01, Julien Grall wrote:
> You can't unselect HAS_PASSTHROUGH support. Given that you are going
> to have passthrough in the future, I don't much see the point to try
> to allow that option to be disabled.
If we are speaking of R-Car Gen3, you might be right. We are targeting
IPMMU support upstreamed. What about IOMMU-less platforms?
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3
2018-04-24 9:52 ` Andrii Anisov
@ 2018-04-24 10:06 ` Julien Grall
2018-04-24 11:04 ` Andrii Anisov
0 siblings, 1 reply; 50+ messages in thread
From: Julien Grall @ 2018-04-24 10:06 UTC (permalink / raw)
To: Andrii Anisov, Stefano Stabellini
Cc: artem_mygaiev, volodymyr_babchuk, xen-devel
On 04/24/2018 10:52 AM, Andrii Anisov wrote:
> Hello Julien,
Hi Andrii,
> On 24.04.18 12:01, Julien Grall wrote:
>> You can't unselect HAS_PASSTHROUGH support. Given that you are going
>> to have passthrough in the future, I don't much see the point to try
>> to allow that option to be disabled.
> If we are speaking of R-Car Gen3, you might be right. We are targeting
> IPMMU support upstreamed. What about IOMMU-less platforms?
For everything you disable, you double the number of configuration
possible. So we have to weight the benefits of disabling some code.
I believe that passthrough should be kept as core Xen, it is small and
quite tight to the rest of Xen.
But I would be interested to know what would be the rationale to disable
that. Do you foresee certification on IOMMU-less platform?
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] 50+ messages in thread
* Re: [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3
2018-04-24 10:06 ` Julien Grall
@ 2018-04-24 11:04 ` Andrii Anisov
2018-04-24 11:16 ` Julien Grall
0 siblings, 1 reply; 50+ messages in thread
From: Andrii Anisov @ 2018-04-24 11:04 UTC (permalink / raw)
To: Julien Grall, Stefano Stabellini
Cc: artem_mygaiev, volodymyr_babchuk, xen-devel
Hello Julien,
On 24.04.18 13:06, Julien Grall wrote:
> I believe that passthrough should be kept as core Xen, it is small and
> quite tight to the rest of Xen.
It might be.
> But I would be interested to know what would be the rationale to
> disable that. Do you foresee certification on IOMMU-less platform?
I would give TI Jacinto6 as an example. It is an automotive focused SoC,
has no IOMMU. BTW, I have a strong feeling that some J6 based automotive
systems with XEN already reached production stage. I'm not really sure
if they are certified, but anyway.
So, yes, I'm pretty sure IOMMU-less platforms with XEN would require
certification.
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3
2018-04-24 11:04 ` Andrii Anisov
@ 2018-04-24 11:16 ` Julien Grall
2018-04-24 14:18 ` Andrii Anisov
0 siblings, 1 reply; 50+ messages in thread
From: Julien Grall @ 2018-04-24 11:16 UTC (permalink / raw)
To: Andrii Anisov, Stefano Stabellini
Cc: artem_mygaiev, nd, volodymyr_babchuk, xen-devel
On 24/04/2018 12:04, Andrii Anisov wrote:
> Hello Julien,
>
>
> On 24.04.18 13:06, Julien Grall wrote:
>> I believe that passthrough should be kept as core Xen, it is small and
>> quite tight to the rest of Xen.
> It might be.
>
>> But I would be interested to know what would be the rationale to
>> disable that. Do you foresee certification on IOMMU-less platform?
> I would give TI Jacinto6 as an example. It is an automotive focused SoC,
> has no IOMMU. BTW, I have a strong feeling that some J6 based automotive
> systems with XEN already reached production stage. I'm not really sure
> if they are certified, but anyway.
> So, yes, I'm pretty sure IOMMU-less platforms with XEN would require
> certification.
Can you quantify what would be the cost of keeping that code around for
IOMMU-less platform?
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] 50+ messages in thread
* Re: [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3
2018-04-24 11:16 ` Julien Grall
@ 2018-04-24 14:18 ` Andrii Anisov
2018-04-24 16:20 ` Julien Grall
0 siblings, 1 reply; 50+ messages in thread
From: Andrii Anisov @ 2018-04-24 14:18 UTC (permalink / raw)
To: Julien Grall, Stefano Stabellini
Cc: artem_mygaiev, nd, volodymyr_babchuk, xen-devel
> Can you quantify what would be the cost of keeping that code around
> for IOMMU-less platform?
I'm not sure I understand your question. Do you mean a number of loc of
the passthrough feature for arm?
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3
2018-04-24 14:18 ` Andrii Anisov
@ 2018-04-24 16:20 ` Julien Grall
2018-05-19 1:15 ` Stefano Stabellini
0 siblings, 1 reply; 50+ messages in thread
From: Julien Grall @ 2018-04-24 16:20 UTC (permalink / raw)
To: Andrii Anisov, Stefano Stabellini
Cc: artem_mygaiev, nd, volodymyr_babchuk, xen-devel
Hi,
On 04/24/2018 03:18 PM, Andrii Anisov wrote:
>
>> Can you quantify what would be the cost of keeping that code around
>> for IOMMU-less platform?
> I'm not sure I understand your question. Do you mean a number of loc of
> the passthrough feature for arm?
I meant that disabling something in Xen will come with a cost. While for
a driver the maintenance is fairly minimal for anything touching core
Xen it will require some more work for any change. So I understand that
it will make Xen slightly smaller (~600 lines), but at what cost?
In other words, I am all for disabling unnecessary driver in Xen with
some caveats (see my other answers). But I am quite worry on the burden
for anything else without any real assessment.
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] 50+ messages in thread
* Re: [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3
2018-04-24 16:20 ` Julien Grall
@ 2018-05-19 1:15 ` Stefano Stabellini
0 siblings, 0 replies; 50+ messages in thread
From: Stefano Stabellini @ 2018-05-19 1:15 UTC (permalink / raw)
To: Julien Grall
Cc: artem_mygaiev, Stefano Stabellini, Andrii Anisov, xen-devel, nd,
volodymyr_babchuk
On Tue, 24 Apr 2018, Julien Grall wrote:
> Hi,
>
> On 04/24/2018 03:18 PM, Andrii Anisov wrote:
> >
> > > Can you quantify what would be the cost of keeping that code around for
> > > IOMMU-less platform?
> > I'm not sure I understand your question. Do you mean a number of loc of the
> > passthrough feature for arm?
>
> I meant that disabling something in Xen will come with a cost. While for a
> driver the maintenance is fairly minimal for anything touching core Xen it
> will require some more work for any change. So I understand that it will make
> Xen slightly smaller (~600 lines), but at what cost?
>
> In other words, I am all for disabling unnecessary driver in Xen with some
> caveats (see my other answers). But I am quite worry on the burden for
> anything else without any real assessment.
It is very difficult to quantify the cost of adding a new Kconfig, I
don't think anybody would be able to answer that question :-)
But I think you have a point. When adding Kconfig options, it is easy to
forget the trade-offs and start adding one for everything. However, the
less self-contained the code, the higher the maintenance cost of the new
option.
PASSTHROUGH is an example of something very small in terms of lines of
code and not quite self-contained. A great example of something that
is probably not worth making optional.
My idea is to start from the low hanging fruits with high value returns
(lots of lines of code to remove). Once we are done with those, we can
go back and evaluate things like PASSTHROUGH.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH 5/6] arm: add a small kconfig for qemu-system-aarch64
2018-04-18 22:15 [PATCH 0/6] arm: more kconfig configurability and small default configs Stefano Stabellini
` (3 preceding siblings ...)
2018-04-18 22:15 ` [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3 Stefano Stabellini
@ 2018-04-18 22:15 ` Stefano Stabellini
2018-04-18 22:15 ` [PATCH 6/6] xen: add cloc target Stefano Stabellini
` (3 subsequent siblings)
8 siblings, 0 replies; 50+ messages in thread
From: Stefano Stabellini @ 2018-04-18 22:15 UTC (permalink / raw)
To: julien.grall; +Cc: sstabellini, 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>
---
xen/arch/arm/configs/qemu.config | 81 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 81 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..6351cfd
--- /dev/null
+++ b/xen/arch/arm/configs/qemu.config
@@ -0,0 +1,81 @@
+#
+# Automatically generated file; DO NOT EDIT.
+# Xen/arm 4.11-unstable Configuration
+#
+CONFIG_64BIT=y
+CONFIG_ARM_64=y
+CONFIG_ARM=y
+CONFIG_ARCH_DEFCONFIG="arch/arm/configs/arm64_defconfig"
+
+#
+# Architecture Features
+#
+CONFIG_NR_CPUS=4
+# CONFIG_ACPI is not set
+CONFIG_HAS_GICV3=y
+# CONFIG_HAS_MEM_ACCESS is not set
+# CONFIG_HAS_ITS is not set
+# CONFIG_NEW_VGIC 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
+CONFIG_HARDEN_BRANCH_PREDICTOR=y
+CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR=y
+
+#
+# Common Features
+#
+CONFIG_HAS_ALTERNATIVE=y
+CONFIG_HAS_DEVICE_TREE=y
+CONFIG_HAS_PDX=y
+# CONFIG_TMEM is not set
+# CONFIG_XSM is not set
+
+#
+# Schedulers
+#
+CONFIG_SCHED_CREDIT=y
+# CONFIG_SCHED_CREDIT2 is not set
+# CONFIG_SCHED_RTDS is not set
+# CONFIG_SCHED_ARINC653 is not set
+CONFIG_SCHED_NULL=y
+CONFIG_SCHED_CREDIT_DEFAULT=y
+# CONFIG_SCHED_NULL_DEFAULT is not set
+CONFIG_SCHED_DEFAULT="credit"
+# CONFIG_LIVEPATCH is not set
+# CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set
+CONFIG_CMDLINE=""
+
+#
+# Device Drivers
+#
+# CONFIG_HAS_NS16550 is not set
+# CONFIG_HAS_CADENCE_UART is not set
+# CONFIG_HAS_MVEBU is not set
+CONFIG_HAS_PL011=y
+# CONFIG_HAS_SCIF is not set
+# CONFIG_HAS_EHCI is not set
+CONFIG_HAS_PASSTHROUGH=y
+# CONFIG_HAS_SMMUv2 is not set
+# CONFIG_VIDEO is not set
+# CONFIG_HAS_ARM_HDLCD is not set
+CONFIG_DEFCONFIG_LIST="$ARCH_DEFCONFIG"
+
+#
+# Debugging Options
+#
+# CONFIG_DEBUG is not set
+# CONFIG_FRAME_POINTER is not set
+# CONFIG_COVERAGE is not set
+# CONFIG_LOCK_PROFILE is not set
+# CONFIG_PERF_COUNTERS is not set
+# CONFIG_VERBOSE_DEBUG is not set
+# CONFIG_DEVICE_TREE_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] 50+ messages in thread
* [PATCH 6/6] xen: add cloc target
2018-04-18 22:15 [PATCH 0/6] arm: more kconfig configurability and small default configs Stefano Stabellini
` (4 preceding siblings ...)
2018-04-18 22:15 ` [PATCH 5/6] arm: add a small kconfig for qemu-system-aarch64 Stefano Stabellini
@ 2018-04-18 22:15 ` Stefano Stabellini
2018-04-19 7:54 ` Jan Beulich
2018-04-19 15:31 ` [PATCH 0/6] arm: more kconfig configurability and small default configs Julien Grall
` (2 subsequent siblings)
8 siblings, 1 reply; 50+ messages in thread
From: Stefano Stabellini @ 2018-04-18 22:15 UTC (permalink / raw)
To: julien.grall; +Cc: andrew.cooper3, sstabellini, 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.
Generate the list of source files from the %.o targets, append output
to "sourcelist".
Remove sourcelist on clean, and also at the beginning of the build
target to avoid appending to sourcelist on consequence builds. Otherwise
one could imagine sourcelist could become large if the user builds Xen
repeatedly without calling clean.
For the cloc target, first clean, then build to make sure all files are
properly accounted (no partial builds).
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
CC: jbeulich@suse.com
CC: andrew.cooper3@citrix.com
---
xen/Makefile | 14 ++++++++++++--
xen/Rules.mk | 2 ++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/xen/Makefile b/xen/Makefile
index 62d479c..f53fd22 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -48,7 +48,7 @@ else
endif
.PHONY: _build
-_build: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
+_build: clean-sourcelist $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
.PHONY: _install
_install: D=$(DESTDIR)
@@ -108,7 +108,7 @@ _debug:
$(OBJDUMP) -D -S $(TARGET)-syms > $(TARGET).s
.PHONY: _clean
-_clean: delete-unfresh-files
+_clean: delete-unfresh-files clean-sourcelist
$(MAKE) -C tools clean
$(MAKE) -f $(BASEDIR)/Rules.mk -C include clean
$(MAKE) -f $(BASEDIR)/Rules.mk -C common clean
@@ -267,3 +267,13 @@ $(KCONFIG_CONFIG):
include/config/auto.conf.cmd: ;
-include $(BASEDIR)/include/config/auto.conf.cmd
+
+.PHONY: cloc
+cloc: $(BASEDIR)/sourcelist
+ cloc --list-file=$(BASEDIR)/sourcelist
+
+$(BASEDIR)/sourcelist: clean build
+
+.PHONY: clean-sourcelist
+clean-sourcelist:
+ rm -f $(BASEDIR)/sourcelist
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 5337e20..cb48aa7 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -190,9 +190,11 @@ _clean_%/: FORCE
$(MAKE) -f $(BASEDIR)/Rules.mk -C $* clean
%.o: %.c Makefile
+ echo `pwd`/$< >> $(BASEDIR)/sourcelist
$(CC) $(CFLAGS) -c $< -o $@
%.o: %.S Makefile
+ echo `pwd`/$< >> $(BASEDIR)/sourcelist
$(CC) $(AFLAGS) -c $< -o $@
SPECIAL_DATA_SECTIONS := rodata $(foreach a,1 2 4 8 16, \
--
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] 50+ messages in thread
* Re: [PATCH 6/6] xen: add cloc target
2018-04-18 22:15 ` [PATCH 6/6] xen: add cloc target Stefano Stabellini
@ 2018-04-19 7:54 ` Jan Beulich
2018-04-19 23:22 ` Stefano Stabellini
0 siblings, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2018-04-19 7:54 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Andrew Cooper, Julien Grall, xen-devel
>>> On 19.04.18 at 00:15, <sstabellini@kernel.org> wrote:
> Add a Xen build target to count the lines of code of the source files
> built. Uses `cloc' to do the job.
>
> Generate the list of source files from the %.o targets, append output
> to "sourcelist".
>
> Remove sourcelist on clean, and also at the beginning of the build
> target to avoid appending to sourcelist on consequence builds. Otherwise
> one could imagine sourcelist could become large if the user builds Xen
> repeatedly without calling clean.
>
> For the cloc target, first clean, then build to make sure all files are
> properly accounted (no partial builds).
>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
All fine, but what I'm missing is why we want something like this in the
first place.
> ---
> xen/Makefile | 14 ++++++++++++--
> xen/Rules.mk | 2 ++
> 2 files changed, 14 insertions(+), 2 deletions(-)
.gitignore ?
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -48,7 +48,7 @@ else
> endif
>
> .PHONY: _build
> -_build: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
> +_build: clean-sourcelist $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
Both here and ...
> @@ -267,3 +267,13 @@ $(KCONFIG_CONFIG):
> include/config/auto.conf.cmd: ;
>
> -include $(BASEDIR)/include/config/auto.conf.cmd
> +
> +.PHONY: cloc
> +cloc: $(BASEDIR)/sourcelist
> + cloc --list-file=$(BASEDIR)/sourcelist
> +
> +$(BASEDIR)/sourcelist: clean build
... here I'm afraid the dependencies aren't right: All dependencies can
be handled in parallel by make, i.e. there's no ordering implication from
the ordering you provide here.
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -190,9 +190,11 @@ _clean_%/: FORCE
> $(MAKE) -f $(BASEDIR)/Rules.mk -C $* clean
>
> %.o: %.c Makefile
> + echo `pwd`/$< >> $(BASEDIR)/sourcelist
> $(CC) $(CFLAGS) -c $< -o $@
>
> %.o: %.S Makefile
> + echo `pwd`/$< >> $(BASEDIR)/sourcelist
> $(CC) $(AFLAGS) -c $< -o $@
For one I'd prefer if this file was written only when actually processing
the "cloc" target you add. And then - is echo guaranteed to produce all
its output with a single atomic write? Otherwise you risk producing a
complete mess in sourcelist if someone hands -j to make.
Furthermore - are e.g. header files not counting at all?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 6/6] xen: add cloc target
2018-04-19 7:54 ` Jan Beulich
@ 2018-04-19 23:22 ` Stefano Stabellini
2018-04-20 9:57 ` Jan Beulich
0 siblings, 1 reply; 50+ messages in thread
From: Stefano Stabellini @ 2018-04-19 23:22 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andrew Cooper, Julien Grall, Stefano Stabellini, xen-devel
On Thu, 19 Apr 2018, Jan Beulich wrote:
> >>> On 19.04.18 at 00:15, <sstabellini@kernel.org> wrote:
> > Add a Xen build target to count the lines of code of the source files
> > built. Uses `cloc' to do the job.
> >
> > Generate the list of source files from the %.o targets, append output
> > to "sourcelist".
> >
> > Remove sourcelist on clean, and also at the beginning of the build
> > target to avoid appending to sourcelist on consequence builds. Otherwise
> > one could imagine sourcelist could become large if the user builds Xen
> > repeatedly without calling clean.
> >
> > For the cloc target, first clean, then build to make sure all files are
> > properly accounted (no partial builds).
> >
> > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
>
> All fine, but what I'm missing is why we want something like this in the
> first place.
I provided an explanation here:
https://marc.info/?l=xen-devel&m=152417791426130, but I can elaborate
more if you have questions.
Thanks for the sharp review.
> > ---
> > xen/Makefile | 14 ++++++++++++--
> > xen/Rules.mk | 2 ++
> > 2 files changed, 14 insertions(+), 2 deletions(-)
>
> .gitignore ?
Good point, I'll add sourcelist to .gitignore
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -48,7 +48,7 @@ else
> > endif
> >
> > .PHONY: _build
> > -_build: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
> > +_build: clean-sourcelist $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
>
> Both here and ...
>
> > @@ -267,3 +267,13 @@ $(KCONFIG_CONFIG):
> > include/config/auto.conf.cmd: ;
> >
> > -include $(BASEDIR)/include/config/auto.conf.cmd
> > +
> > +.PHONY: cloc
> > +cloc: $(BASEDIR)/sourcelist
> > + cloc --list-file=$(BASEDIR)/sourcelist
> > +
> > +$(BASEDIR)/sourcelist: clean build
>
> ... here I'm afraid the dependencies aren't right: All dependencies can
> be handled in parallel by make, i.e. there's no ordering implication from
> the ordering you provide here.
I see what you mean. Nasty. Do you have a suggestion on how to better
handle this kind of thing?
> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -190,9 +190,11 @@ _clean_%/: FORCE
> > $(MAKE) -f $(BASEDIR)/Rules.mk -C $* clean
> >
> > %.o: %.c Makefile
> > + echo `pwd`/$< >> $(BASEDIR)/sourcelist
> > $(CC) $(CFLAGS) -c $< -o $@
> >
> > %.o: %.S Makefile
> > + echo `pwd`/$< >> $(BASEDIR)/sourcelist
> > $(CC) $(AFLAGS) -c $< -o $@
>
> For one I'd prefer if this file was written only when actually processing
> the "cloc" target you add.
I can make the echo command conditional on the cloc target using a
global flag.
> And then - is echo guaranteed to produce all
> its output with a single atomic write? Otherwise you risk producing a
> complete mess in sourcelist if someone hands -j to make.
I haven't seen this issue in my tests so far. POSIX guarantees that
write requests of PIPE_BUF bytes or less shall not be interleaved.
PIPE_BUF is 4K on Linux and is always greater than 512, which should be
fine here. Therefore it is down to the echo implementation, as you
pointed out.
Honestly, I would prefer to trust the echo implementation to do the
right thing, and risk a corruption in sourcelist, rather than
introducing file locks to solve the problem. What is your take on this?
> Furthermore - are e.g. header files not counting at all?
I have been wondering about that too. I am not sure, but I have seen
other LOC counts in the past ignoring header files. In any case, I
thought that C and ASM files would be a good start.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 6/6] xen: add cloc target
2018-04-19 23:22 ` Stefano Stabellini
@ 2018-04-20 9:57 ` Jan Beulich
2018-05-21 23:32 ` Stefano Stabellini
0 siblings, 1 reply; 50+ messages in thread
From: Jan Beulich @ 2018-04-20 9:57 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Andrew Cooper, Julien Grall, xen-devel
>>> On 20.04.18 at 01:22, <sstabellini@kernel.org> wrote:
> On Thu, 19 Apr 2018, Jan Beulich wrote:
>> >>> On 19.04.18 at 00:15, <sstabellini@kernel.org> wrote:
>> > Add a Xen build target to count the lines of code of the source files
>> > built. Uses `cloc' to do the job.
>> >
>> > Generate the list of source files from the %.o targets, append output
>> > to "sourcelist".
>> >
>> > Remove sourcelist on clean, and also at the beginning of the build
>> > target to avoid appending to sourcelist on consequence builds. Otherwise
>> > one could imagine sourcelist could become large if the user builds Xen
>> > repeatedly without calling clean.
>> >
>> > For the cloc target, first clean, then build to make sure all files are
>> > properly accounted (no partial builds).
>> >
>> > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
>>
>> All fine, but what I'm missing is why we want something like this in the
>> first place.
>
> I provided an explanation here:
> https://marc.info/?l=xen-devel&m=152417791426130, but I can elaborate
> more if you have questions.
Yeah with that explanation I can see where you're coming from. Some
of that needs to go into the commit message here though.
>> > --- a/xen/Makefile
>> > +++ b/xen/Makefile
>> > @@ -48,7 +48,7 @@ else
>> > endif
>> >
>> > .PHONY: _build
>> > -_build: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
>> > +_build: clean-sourcelist $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
>>
>> Both here and ...
>>
>> > @@ -267,3 +267,13 @@ $(KCONFIG_CONFIG):
>> > include/config/auto.conf.cmd: ;
>> >
>> > -include $(BASEDIR)/include/config/auto.conf.cmd
>> > +
>> > +.PHONY: cloc
>> > +cloc: $(BASEDIR)/sourcelist
>> > + cloc --list-file=$(BASEDIR)/sourcelist
>> > +
>> > +$(BASEDIR)/sourcelist: clean build
>>
>> ... here I'm afraid the dependencies aren't right: All dependencies can
>> be handled in parallel by make, i.e. there's no ordering implication from
>> the ordering you provide here.
>
> I see what you mean. Nasty. Do you have a suggestion on how to better
> handle this kind of thing?
I think you'll need intermediate (pseudo-)targets, or you need to invoke the
second step as command instead of that being a dependency.
>> > --- a/xen/Rules.mk
>> > +++ b/xen/Rules.mk
>> > @@ -190,9 +190,11 @@ _clean_%/: FORCE
>> > $(MAKE) -f $(BASEDIR)/Rules.mk -C $* clean
>> >
>> > %.o: %.c Makefile
>> > + echo `pwd`/$< >> $(BASEDIR)/sourcelist
>> > $(CC) $(CFLAGS) -c $< -o $@
>> >
>> > %.o: %.S Makefile
>> > + echo `pwd`/$< >> $(BASEDIR)/sourcelist
>> > $(CC) $(AFLAGS) -c $< -o $@
>>
>> For one I'd prefer if this file was written only when actually processing
>> the "cloc" target you add.
>
> I can make the echo command conditional on the cloc target using a
> global flag.
A global flag would mean ifdef-ary here, which I'd like to avoid. Instead I
was hoping for you to define a macro which expands to nothing in the
non-cloc target case.
>> And then - is echo guaranteed to produce all
>> its output with a single atomic write? Otherwise you risk producing a
>> complete mess in sourcelist if someone hands -j to make.
>
> I haven't seen this issue in my tests so far. POSIX guarantees that
> write requests of PIPE_BUF bytes or less shall not be interleaved.
> PIPE_BUF is 4K on Linux and is always greater than 512, which should be
> fine here. Therefore it is down to the echo implementation, as you
> pointed out.
>
> Honestly, I would prefer to trust the echo implementation to do the
> right thing, and risk a corruption in sourcelist, rather than
> introducing file locks to solve the problem. What is your take on this?
Can't you use a different approach altogether, e.g. grep-ing the
.*.d files once the whole build is done?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 6/6] xen: add cloc target
2018-04-20 9:57 ` Jan Beulich
@ 2018-05-21 23:32 ` Stefano Stabellini
0 siblings, 0 replies; 50+ messages in thread
From: Stefano Stabellini @ 2018-05-21 23:32 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andrew Cooper, Julien Grall, Stefano Stabellini, xen-devel
On Fri, 20 Apr 2018, Jan Beulich wrote:
> >>> On 20.04.18 at 01:22, <sstabellini@kernel.org> wrote:
> > On Thu, 19 Apr 2018, Jan Beulich wrote:
> >> >>> On 19.04.18 at 00:15, <sstabellini@kernel.org> wrote:
> >> > Add a Xen build target to count the lines of code of the source files
> >> > built. Uses `cloc' to do the job.
> >> >
> >> > Generate the list of source files from the %.o targets, append output
> >> > to "sourcelist".
> >> >
> >> > Remove sourcelist on clean, and also at the beginning of the build
> >> > target to avoid appending to sourcelist on consequence builds. Otherwise
> >> > one could imagine sourcelist could become large if the user builds Xen
> >> > repeatedly without calling clean.
> >> >
> >> > For the cloc target, first clean, then build to make sure all files are
> >> > properly accounted (no partial builds).
> >> >
> >> > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> >>
> >> All fine, but what I'm missing is why we want something like this in the
> >> first place.
> >
> > I provided an explanation here:
> > https://marc.info/?l=xen-devel&m=152417791426130, but I can elaborate
> > more if you have questions.
>
> Yeah with that explanation I can see where you're coming from. Some
> of that needs to go into the commit message here though.
>
> >> > --- a/xen/Makefile
> >> > +++ b/xen/Makefile
> >> > @@ -48,7 +48,7 @@ else
> >> > endif
> >> >
> >> > .PHONY: _build
> >> > -_build: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
> >> > +_build: clean-sourcelist $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
> >>
> >> Both here and ...
> >>
> >> > @@ -267,3 +267,13 @@ $(KCONFIG_CONFIG):
> >> > include/config/auto.conf.cmd: ;
> >> >
> >> > -include $(BASEDIR)/include/config/auto.conf.cmd
> >> > +
> >> > +.PHONY: cloc
> >> > +cloc: $(BASEDIR)/sourcelist
> >> > + cloc --list-file=$(BASEDIR)/sourcelist
> >> > +
> >> > +$(BASEDIR)/sourcelist: clean build
> >>
> >> ... here I'm afraid the dependencies aren't right: All dependencies can
> >> be handled in parallel by make, i.e. there's no ordering implication from
> >> the ordering you provide here.
> >
> > I see what you mean. Nasty. Do you have a suggestion on how to better
> > handle this kind of thing?
>
> I think you'll need intermediate (pseudo-)targets, or you need to invoke the
> second step as command instead of that being a dependency.
>
> >> > --- a/xen/Rules.mk
> >> > +++ b/xen/Rules.mk
> >> > @@ -190,9 +190,11 @@ _clean_%/: FORCE
> >> > $(MAKE) -f $(BASEDIR)/Rules.mk -C $* clean
> >> >
> >> > %.o: %.c Makefile
> >> > + echo `pwd`/$< >> $(BASEDIR)/sourcelist
> >> > $(CC) $(CFLAGS) -c $< -o $@
> >> >
> >> > %.o: %.S Makefile
> >> > + echo `pwd`/$< >> $(BASEDIR)/sourcelist
> >> > $(CC) $(AFLAGS) -c $< -o $@
> >>
> >> For one I'd prefer if this file was written only when actually processing
> >> the "cloc" target you add.
> >
> > I can make the echo command conditional on the cloc target using a
> > global flag.
>
> A global flag would mean ifdef-ary here, which I'd like to avoid. Instead I
> was hoping for you to define a macro which expands to nothing in the
> non-cloc target case.
>
> >> And then - is echo guaranteed to produce all
> >> its output with a single atomic write? Otherwise you risk producing a
> >> complete mess in sourcelist if someone hands -j to make.
> >
> > I haven't seen this issue in my tests so far. POSIX guarantees that
> > write requests of PIPE_BUF bytes or less shall not be interleaved.
> > PIPE_BUF is 4K on Linux and is always greater than 512, which should be
> > fine here. Therefore it is down to the echo implementation, as you
> > pointed out.
> >
> > Honestly, I would prefer to trust the echo implementation to do the
> > right thing, and risk a corruption in sourcelist, rather than
> > introducing file locks to solve the problem. What is your take on this?
>
> Can't you use a different approach altogether, e.g. grep-ing the
> .*.d files once the whole build is done?
Actually, it seems possible. It feels a bit haskish to me, but it has
the benefit of having no impacts whatsoever to the normal build. I'll
change approach to what you suggested.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 0/6] arm: more kconfig configurability and small default configs
2018-04-18 22:15 [PATCH 0/6] arm: more kconfig configurability and small default configs Stefano Stabellini
` (5 preceding siblings ...)
2018-04-18 22:15 ` [PATCH 6/6] xen: add cloc target Stefano Stabellini
@ 2018-04-19 15:31 ` Julien Grall
2018-04-19 17:34 ` Lars Kurth
2018-04-23 18:05 ` Andrii Anisov
2018-04-23 18:08 ` Andrii Anisov
8 siblings, 1 reply; 50+ messages in thread
From: Julien Grall @ 2018-04-19 15:31 UTC (permalink / raw)
To: Stefano Stabellini
Cc: artem_mygaiev, lars.kurth, andrii_anisov, George Dunlap,
Andrew Cooper, Ian Jackson, dfaggioli, Jan Beulich, Wei Liu,
xen-devel
On 18/04/18 23:15, Stefano Stabellini wrote:
> Hi all,
Hi,
> 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).
While I could be tempt by more option to be configurable in Kconfig with
some caveats (see below), I quite dislike the idea of providing a config
per board. A few reasons:
- Where do we draw the line on config we accept for a given board?
- Do we have to test them every release?
- What if we add a new option?
- What does it mean in term of security support?
Regarding the Kconfig, allowing more option to be selected by the user
means that it will increasingly be more difficult for the community to
help user in debug. More that we today don't provide a way to embed the
.config in Xen binary. So if you happen to clean you repo, then you are
screw to reproduce it.
Furthermore, if we decide to impose CONFIG_XEN_EXPERT=y when using those
.config, then you happen to drop one by mistake you end up rewrite you
.config which is not really nice.
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] 50+ messages in thread
* Re: [PATCH 0/6] arm: more kconfig configurability and small default configs
2018-04-19 15:31 ` [PATCH 0/6] arm: more kconfig configurability and small default configs Julien Grall
@ 2018-04-19 17:34 ` Lars Kurth
2018-04-19 22:45 ` Stefano Stabellini
0 siblings, 1 reply; 50+ messages in thread
From: Lars Kurth @ 2018-04-19 17:34 UTC (permalink / raw)
To: Julien Grall, Stefano Stabellini
Cc: artem_mygaiev, andrii_anisov, Andrew Cooper, George Dunlap,
dfaggioli, Jan Beulich, Ian Jackson, Wei Liu, xen-devel
On 19/04/2018, 17:32, "Julien Grall" <julien.grall@arm.com> wrote:
On 18/04/18 23:15, Stefano Stabellini wrote:
> Hi all,
Hi,
> 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).
While I could be tempt by more option to be configurable in Kconfig with
some caveats (see below), I quite dislike the idea of providing a config
per board. A few reasons:
- Where do we draw the line on config we accept for a given board?
- Do we have to test them every release?
- What if we add a new option?
- What does it mean in term of security support?
Regarding the Kconfig, allowing more option to be selected by the user
means that it will increasingly be more difficult for the community to
help user in debug. More that we today don't provide a way to embed the
.config in Xen binary. So if you happen to clean you repo, then you are
screw to reproduce it.
Furthermore, if we decide to impose CONFIG_XEN_EXPERT=y when using those
.config, then you happen to drop one by mistake you end up rewrite you
.config which is not really nice.
Maybe the easiest way to solve this is to emit the config into the serial output. That should be easy enough to implement while not requiring any ABI/interface changes
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 0/6] arm: more kconfig configurability and small default configs
2018-04-19 17:34 ` Lars Kurth
@ 2018-04-19 22:45 ` Stefano Stabellini
0 siblings, 0 replies; 50+ messages in thread
From: Stefano Stabellini @ 2018-04-19 22:45 UTC (permalink / raw)
To: Lars Kurth
Cc: artem_mygaiev, Stefano Stabellini, andrii_anisov, Andrew Cooper,
George Dunlap, dfaggioli, Julien Grall, Jan Beulich, Ian Jackson,
Wei Liu, xen-devel
On Thu, 19 Apr 2018, Lars Kurth wrote:
> 19/04/2018, 17:32, "Julien Grall" <julien.grall@arm.com> wrote:
>
>
>
> On 18/04/18 23:15, Stefano Stabellini wrote:
> > Hi all,
>
> Hi,
>
> > 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).
>
> While I could be tempt by more option to be configurable in Kconfig with
> some caveats (see below), I quite dislike the idea of providing a config
> per board. A few reasons:
> - Where do we draw the line on config we accept for a given board?
> - Do we have to test them every release?
> - What if we add a new option?
I discussed this topic with Julien over a call this morning. It seems to
us that the best way forward is to follow this simple rule:
* Only accept and keep kconfig that are regularly tested for each release *
We already maintain a table of supported boards for Xen on ARM. We ask
members of the community to test Xen on these boards during the code
freeze. We mark as supported only the ones for which we get positive
responses.
In this case, if nobody steps up to test Xen with a specific kconfig
during the code freeze, the kconfig will be dropped.
> - What does it mean in term of security support?
I replied to this question here:
https://marc.info/?l=xen-devel&m=152417791426130
> Regarding the Kconfig, allowing more option to be selected by the user
> means that it will increasingly be more difficult for the community to
> help user in debug. More that we today don't provide a way to embed the
> .config in Xen binary. So if you happen to clean you repo, then you are
> screw to reproduce it.
>
> Furthermore, if we decide to impose CONFIG_XEN_EXPERT=y when using those
> .config, then you happen to drop one by mistake you end up rewrite you
> .config which is not really nice.
>
> Maybe the easiest way to solve this is to emit the config into the serial output. That should be easy enough to implement while not requiring any ABI/interface changes
We have a better idea: we can embedded the kconfig into the Xen binary.
In fact, we even have a Jira ticket for it already:
https://xenproject.atlassian.net/browse/XEN-38
I'll try to come up with a patch and make it part of this series.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 0/6] arm: more kconfig configurability and small default configs
2018-04-18 22:15 [PATCH 0/6] arm: more kconfig configurability and small default configs Stefano Stabellini
` (6 preceding siblings ...)
2018-04-19 15:31 ` [PATCH 0/6] arm: more kconfig configurability and small default configs Julien Grall
@ 2018-04-23 18:05 ` Andrii Anisov
2018-04-23 18:08 ` Andrii Anisov
8 siblings, 0 replies; 50+ messages in thread
From: Andrii Anisov @ 2018-04-23 18:05 UTC (permalink / raw)
To: Stefano Stabellini, julien.grall
Cc: artem_mygaiev, lars.kurth, dfaggioli, xen-devel
Hello Stefano,
I'm really glad to see this series.
In the list of platform-specific bits you are trying to make selectable,
you missed platform support code itself. Moreover, as it is said in your
follow-up emails, set of UART, IOMMU, GIC is defined by SoC family. So
wouldn't it be more natural to introduce platform configs which would
couple specific drivers support? With a special platform i.e. "other"
which enables all drivers and platform code.
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 0/6] arm: more kconfig configurability and small default configs
2018-04-18 22:15 [PATCH 0/6] arm: more kconfig configurability and small default configs Stefano Stabellini
` (7 preceding siblings ...)
2018-04-23 18:05 ` Andrii Anisov
@ 2018-04-23 18:08 ` Andrii Anisov
2018-05-21 23:45 ` Stefano Stabellini
8 siblings, 1 reply; 50+ messages in thread
From: Andrii Anisov @ 2018-04-23 18:08 UTC (permalink / raw)
To: Stefano Stabellini, julien.grall
Cc: artem_mygaiev, lars.kurth, dfaggioli, xen-devel
Hello Stefano,
I'm really glad to see this series.
In the list of platform-specific bits you are trying to make selectable,
you missed platform support code itself. Moreover, as it is said in your
follow-up emails, set of UART, IOMMU, GIC is defined by SoC family. So
wouldn't it be more natural to introduce platform configs which would
couple specific drivers support? With a special platform i.e. "other"
which enables all drivers and platform code.
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 0/6] arm: more kconfig configurability and small default configs
2018-04-23 18:08 ` Andrii Anisov
@ 2018-05-21 23:45 ` Stefano Stabellini
2018-05-23 17:48 ` Andrii Anisov
0 siblings, 1 reply; 50+ messages in thread
From: Stefano Stabellini @ 2018-05-21 23:45 UTC (permalink / raw)
To: Andrii Anisov
Cc: artem_mygaiev, lars.kurth, Stefano Stabellini, xen-devel,
julien.grall, dfaggioli
On Mon, 23 Apr 2018, Andrii Anisov wrote:
> Hello Stefano,
>
> I'm really glad to see this series.
>
> In the list of platform-specific bits you are trying to make selectable, you
> missed platform support code itself. Moreover, as it is said in your follow-up
> emails, set of UART, IOMMU, GIC is defined by SoC family. So wouldn't it be
> more natural to introduce platform configs which would couple specific drivers
> support? With a special platform i.e. "other" which enables all drivers and
> platform code.
I am not sure I understand your suggestion. But I think we are heading
in the direction you are hinting toward with Juergen's suggestion to
only keep kconfig options that are not "default". If you give a look at
v2, the rcar3.config is smaller and doesn't have much more than the
basic drivers for the platform.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 0/6] arm: more kconfig configurability and small default configs
2018-05-21 23:45 ` Stefano Stabellini
@ 2018-05-23 17:48 ` Andrii Anisov
0 siblings, 0 replies; 50+ messages in thread
From: Andrii Anisov @ 2018-05-23 17:48 UTC (permalink / raw)
To: Stefano Stabellini
Cc: artem_mygaiev, lars.kurth, julien.grall, xen-devel, dfaggioli
Hello Stefano,
On 22.05.18 02:45, Stefano Stabellini wrote:
> I am not sure I understand your suggestion. But I think we are heading
> in the direction you are hinting toward with Juergen's suggestion to
> only keep kconfig options that are not "default". If you give a look at
> v2, the rcar3.config is smaller and doesn't have much more than the
> basic drivers for the platform.
What I did mean is closer to v3. With one more hint about a selecting
platform code one can find in xen/arch/arm/platforms.
Something like:
diff --git a/xen/arch/arm/platforms/Makefile
b/xen/arch/arm/platforms/Makefile
index 53a47e4..c420318 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -7,4 +7,4 @@ obj-$(CONFIG_ARM_32) += rcar2.o
obj-$(CONFIG_ARM_64) += seattle.o
obj-y += sunxi.o
obj-$(CONFIG_ARM_64) += xgene-storm.o
-obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
+obj-$(CONFIG_MPSOC) += xilinx-zynqmp.o
Though, RCAR gen3 does not have the platform code yet. So nothing to
select for it now ;)
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread