[PATCH 0/4] xen kconfig tweaks

[PATCH 0/4] xen kconfig tweaks

[Andrew Jones]

This series is a collection of xen kconfig fixes and additions.

Andrew Jones (4):
  xen kconfig: keep XEN_XENBUS_FRONTEND builtin
  xen kconfig: relax INPUT_XEN_KBDDEV_FRONTEND deps
  xen kconfig: add dom0 support help text
  xen kconfig: describe xen tmem in the config menu

 arch/x86/xen/Kconfig       |    7 ++++++-
 drivers/input/misc/Kconfig |    2 +-
 drivers/video/Kconfig      |    1 +
 drivers/xen/Kconfig        |    4 ++--
 4 files changed, 10 insertions(+), 4 deletions(-)

-- 
1.7.7.5

[PATCH 1/4] xen kconfig: keep XEN_XENBUS_FRONTEND builtin

[Andrew Jones]

When XEN_XENBUS_FRONTEND gets selected as a module it can lead to
unbootable configs. If we need it, then we should just build it in.
---
 drivers/xen/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 8795480..1d24061 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -118,7 +118,7 @@ config XEN_SYS_HYPERVISOR
 	 but will have no xen contents.
 
 config XEN_XENBUS_FRONTEND
-	tristate
+	bool
 
 config XEN_GNTDEV
 	tristate "userspace grant access device driver"
-- 
1.7.7.5

[PATCH 2/4] xen kconfig: relax INPUT_XEN_KBDDEV_FRONTEND deps

[Andrew Jones]

PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
they don't use the xen frame buffer frontend. For this case it doesn't
make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
if you're using xenfb, then you'll want xenkbd. Switch the dependencies.
---
 drivers/input/misc/Kconfig |    2 +-
 drivers/video/Kconfig      |    1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 22d875f..36c15bf 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
 
 config INPUT_XEN_KBDDEV_FRONTEND
 	tristate "Xen virtual keyboard and mouse support"
-	depends on XEN_FBDEV_FRONTEND
+	depends on XEN
 	default y
 	select XEN_XENBUS_FRONTEND
 	help
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d83e967..269b299 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
 	select FB_SYS_IMAGEBLIT
 	select FB_SYS_FOPS
 	select FB_DEFERRED_IO
+	select INPUT_XEN_KBDDEV_FRONTEND
 	select XEN_XENBUS_FRONTEND
 	default y
 	help
-- 
1.7.7.5

Re: [PATCH 2/4] xen kconfig: relax INPUT_XEN_KBDDEV_FRONTEND deps

[Stefano Stabellini]

On Fri, 6 Jan 2012, Andrew Jones wrote:
> PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
> they don't use the xen frame buffer frontend. For this case it doesn't
> make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
> if you're using xenfb, then you'll want xenkbd. Switch the dependencies.

ack

> ---
>  drivers/input/misc/Kconfig |    2 +-
>  drivers/video/Kconfig      |    1 +
>  2 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 22d875f..36c15bf 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
>  
>  config INPUT_XEN_KBDDEV_FRONTEND
>  	tristate "Xen virtual keyboard and mouse support"
> -	depends on XEN_FBDEV_FRONTEND
> +	depends on XEN
>  	default y
>  	select XEN_XENBUS_FRONTEND
>  	help
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index d83e967..269b299 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
>  	select FB_SYS_IMAGEBLIT
>  	select FB_SYS_FOPS
>  	select FB_DEFERRED_IO
> +	select INPUT_XEN_KBDDEV_FRONTEND
>  	select XEN_XENBUS_FRONTEND
>  	default y
>  	help
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

Re: [PATCH 2/4] xen kconfig: relax INPUT_XEN_KBDDEV_FRONTEND deps

[Stefano Stabellini]

On Fri, 6 Jan 2012, Stefano Stabellini wrote:
> On Fri, 6 Jan 2012, Andrew Jones wrote:
> > PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
> > they don't use the xen frame buffer frontend. For this case it doesn't
> > make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> > XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
> > if you're using xenfb, then you'll want xenkbd. Switch the dependencies.
> 
> ack

I meant to ack the version you sent with a signed-off-by line

[PATCH 3/4] xen kconfig: add dom0 support help text

[Andrew Jones]

Describe dom0 support in the config menu and supply help text for it.
---
 arch/x86/xen/Kconfig |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 26c731a..88862d5 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -14,9 +14,14 @@ config XEN
 	  Xen hypervisor.
 
 config XEN_DOM0
-	def_bool y
+	bool "Xen Initial Domain (Dom0) support"
+	default y
 	depends on XEN && PCI_XEN && SWIOTLB_XEN
 	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
+	help
+	  This allows the kernel to be used for the initial Xen domain,
+	  Domain0. This is a privileged guest that supplies backends
+	  and is used to manage the other Xen domains.
 
 # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
 # name in tools.
-- 
1.7.7.5

Re: [PATCH 3/4] xen kconfig: add dom0 support help text

[Ian Campbell]

On Fri, 2012-01-06 at 08:57 +0000, Andrew Jones wrote:
> Describe dom0 support in the config menu and supply help text for it.

This turns a non-user visible symbol into a user visible one. Previously
if Xen was enabled and the other prerequisites were met you would get
dom0 support automatically -- do we really want to change that?
According to 6b0661a5e6fbf it was a deliberate decision to have it this
way.

BTW, you forgot a Signed-off-by and the appropriate CCs (please use
MAINTAINERS or ./scripts/get-maintainer.pl).

Ian.

> ---
>  arch/x86/xen/Kconfig |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 26c731a..88862d5 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -14,9 +14,14 @@ config XEN
>  	  Xen hypervisor.
>  
>  config XEN_DOM0
> -	def_bool y
> +	bool "Xen Initial Domain (Dom0) support"
> +	default y
>  	depends on XEN && PCI_XEN && SWIOTLB_XEN
>  	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> +	help
> +	  This allows the kernel to be used for the initial Xen domain,
> +	  Domain0. This is a privileged guest that supplies backends
> +	  and is used to manage the other Xen domains.
>  
>  # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
>  # name in tools.

Re: [PATCH 3/4] xen kconfig: add dom0 support help text

[Andrew Jones]

----- Original Message -----
> On Fri, 2012-01-06 at 08:57 +0000, Andrew Jones wrote:
> > Describe dom0 support in the config menu and supply help text for
> > it.
> 
> This turns a non-user visible symbol into a user visible one.
> Previously
> if Xen was enabled and the other prerequisites were met you would get
> dom0 support automatically -- do we really want to change that?
> According to 6b0661a5e6fbf it was a deliberate decision to have it
> this
> way.

I think it's a necessary evil in order to give users the ability to
compile kernels without the support. I know it doesn't make much sense
for most users, but...

> 
> BTW, you forgot a Signed-off-by and the appropriate CCs (please use
> MAINTAINERS or ./scripts/get-maintainer.pl).
> 

Sorry, I'll resend properly.

Drew

> Ian.
> 
> > ---
> >  arch/x86/xen/Kconfig |    7 ++++++-
> >  1 files changed, 6 insertions(+), 1 deletions(-)
> > 
> > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > index 26c731a..88862d5 100644
> > --- a/arch/x86/xen/Kconfig
> > +++ b/arch/x86/xen/Kconfig
> > @@ -14,9 +14,14 @@ config XEN
> >  	  Xen hypervisor.
> >  
> >  config XEN_DOM0
> > -	def_bool y
> > +	bool "Xen Initial Domain (Dom0) support"
> > +	default y
> >  	depends on XEN && PCI_XEN && SWIOTLB_XEN
> >  	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> > +	help
> > +	  This allows the kernel to be used for the initial Xen domain,
> > +	  Domain0. This is a privileged guest that supplies backends
> > +	  and is used to manage the other Xen domains.
> >  
> >  # Dummy symbol since people have come to rely on the
> >  PRIVILEGED_GUEST
> >  # name in tools.
> 
> 
> 

Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text

[Ian Campbell]

On Fri, 2012-01-06 at 09:26 +0000, Andrew Jones wrote:
> 
> ----- Original Message -----
> > On Fri, 2012-01-06 at 08:57 +0000, Andrew Jones wrote:
> > > Describe dom0 support in the config menu and supply help text for
> > > it.
> > 
> > This turns a non-user visible symbol into a user visible one.
> > Previously
> > if Xen was enabled and the other prerequisites were met you would get
> > dom0 support automatically -- do we really want to change that?
> > According to 6b0661a5e6fbf it was a deliberate decision to have it
> > this
> > way.
> 
> I think it's a necessary evil in order to give users the ability to
> compile kernels without the support. I know it doesn't make much sense
> for most users, but...

Who actually wants to do this though and why? Do you have a bug report
requesting this change?

Almost all of the things which dom0 needs (e.g. PCI device management
etc) is also required by a domU with passthrough enabled so the savings
are really very slight.

We are talking less than 1k of code AFAICT, 319 bytes for
arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
whatever xen_register_gsi (a couple of dozen lines of code) adds to
arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
anywhere else. What savings do you see in practice from disabling just
this symbol?

We need to weigh up the size change against the complexity of asking the
user yet another question, I'm not convinced the question is worth it on
balance.

> > 
> > BTW, you forgot a Signed-off-by and the appropriate CCs (please use
> > MAINTAINERS or ./scripts/get-maintainer.pl).
> > 
> 
> Sorry, I'll resend properly.

I've added those CC's to this reply too.

Ian.

> 
> Drew
> 
> > Ian.
> > 
> > > ---
> > >  arch/x86/xen/Kconfig |    7 ++++++-
> > >  1 files changed, 6 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > > index 26c731a..88862d5 100644
> > > --- a/arch/x86/xen/Kconfig
> > > +++ b/arch/x86/xen/Kconfig
> > > @@ -14,9 +14,14 @@ config XEN
> > >  	  Xen hypervisor.
> > >  
> > >  config XEN_DOM0
> > > -	def_bool y
> > > +	bool "Xen Initial Domain (Dom0) support"
> > > +	default y
> > >  	depends on XEN && PCI_XEN && SWIOTLB_XEN
> > >  	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> > > +	help
> > > +	  This allows the kernel to be used for the initial Xen domain,
> > > +	  Domain0. This is a privileged guest that supplies backends
> > > +	  and is used to manage the other Xen domains.
> > >  
> > >  # Dummy symbol since people have come to rely on the
> > >  PRIVILEGED_GUEST
> > >  # name in tools.
> > 
> > 
> > 

Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text

[Stefano Stabellini]

On Fri, 6 Jan 2012, Ian Campbell wrote:
> On Fri, 2012-01-06 at 09:26 +0000, Andrew Jones wrote:
> > 
> > ----- Original Message -----
> > > On Fri, 2012-01-06 at 08:57 +0000, Andrew Jones wrote:
> > > > Describe dom0 support in the config menu and supply help text for
> > > > it.
> > > 
> > > This turns a non-user visible symbol into a user visible one.
> > > Previously
> > > if Xen was enabled and the other prerequisites were met you would get
> > > dom0 support automatically -- do we really want to change that?
> > > According to 6b0661a5e6fbf it was a deliberate decision to have it
> > > this
> > > way.
> > 
> > I think it's a necessary evil in order to give users the ability to
> > compile kernels without the support. I know it doesn't make much sense
> > for most users, but...
> 
> Who actually wants to do this though and why? Do you have a bug report
> requesting this change?
> 
> Almost all of the things which dom0 needs (e.g. PCI device management
> etc) is also required by a domU with passthrough enabled so the savings
> are really very slight.
> 
> We are talking less than 1k of code AFAICT, 319 bytes for
> arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
> whatever xen_register_gsi (a couple of dozen lines of code) adds to
> arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
> anywhere else. What savings do you see in practice from disabling just
> this symbol?
> 
> We need to weigh up the size change against the complexity of asking the
> user yet another question, I'm not convinced the question is worth it on
> balance.

I agree, there is nothing to gain disabling dom0 support if the
conditions it depends upon are already met.
XEN_DOM0 was meant to be a silent option since the beginning to avoid
unnecessary complexity.

Re: [PATCH 3/4] xen kconfig: add dom0 support help text

[Andrew Jones]

----- Original Message -----
> On Fri, 2012-01-06 at 09:26 +0000, Andrew Jones wrote:
> > 
> > ----- Original Message -----
> > > On Fri, 2012-01-06 at 08:57 +0000, Andrew Jones wrote:
> > > > Describe dom0 support in the config menu and supply help text
> > > > for
> > > > it.
> > > 
> > > This turns a non-user visible symbol into a user visible one.
> > > Previously
> > > if Xen was enabled and the other prerequisites were met you would
> > > get
> > > dom0 support automatically -- do we really want to change that?
> > > According to 6b0661a5e6fbf it was a deliberate decision to have
> > > it
> > > this
> > > way.
> > 
> > I think it's a necessary evil in order to give users the ability to
> > compile kernels without the support. I know it doesn't make much
> > sense
> > for most users, but...
> 
> Who actually wants to do this though and why? Do you have a bug
> report
> requesting this change?
> 

No bug for it. I'll explain the motivation below.

> Almost all of the things which dom0 needs (e.g. PCI device management
> etc) is also required by a domU with passthrough enabled so the
> savings
> are really very slight.
> 
> We are talking less than 1k of code AFAICT, 319 bytes for
> arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
> whatever xen_register_gsi (a couple of dozen lines of code) adds to
> arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
> anywhere else. What savings do you see in practice from disabling
> just
> this symbol?

I completely agree that the saving are near none. The savings, however,
aren't the only reason to drive the change. It's actually the symbol
name itself. Unfortunately configs can be perceived as a contract of
support, i.e. if feature xyz is enabled in the distro's config, then
the distributor must have selected, and therefore will support, said
feature.

I didn't make this motivation clear in my initial post, because I was
hoping to spare people some eye rolling.

> 
> We need to weigh up the size change against the complexity of asking
> the
> user yet another question, I'm not convinced the question is worth it
> on
> balance.
> 

Tons of questions aren't much fun to wade through, but I guess I'm
generally for a config menu complexity that is proportional to
(and controls) the kernel complexity.

Drew

> > > 
> > > BTW, you forgot a Signed-off-by and the appropriate CCs (please
> > > use
> > > MAINTAINERS or ./scripts/get-maintainer.pl).
> > > 
> > 
> > Sorry, I'll resend properly.
> 
> I've added those CC's to this reply too.
> 
> Ian.
> 
> > 
> > Drew
> > 
> > > Ian.
> > > 
> > > > ---
> > > >  arch/x86/xen/Kconfig |    7 ++++++-
> > > >  1 files changed, 6 insertions(+), 1 deletions(-)
> > > > 
> > > > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > > > index 26c731a..88862d5 100644
> > > > --- a/arch/x86/xen/Kconfig
> > > > +++ b/arch/x86/xen/Kconfig
> > > > @@ -14,9 +14,14 @@ config XEN
> > > >  	  Xen hypervisor.
> > > >  
> > > >  config XEN_DOM0
> > > > -	def_bool y
> > > > +	bool "Xen Initial Domain (Dom0) support"
> > > > +	default y
> > > >  	depends on XEN && PCI_XEN && SWIOTLB_XEN
> > > >  	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> > > > +	help
> > > > +	  This allows the kernel to be used for the initial Xen
> > > > domain,
> > > > +	  Domain0. This is a privileged guest that supplies backends
> > > > +	  and is used to manage the other Xen domains.
> > > >  
> > > >  # Dummy symbol since people have come to rely on the
> > > >  PRIVILEGED_GUEST
> > > >  # name in tools.
> > > 
> > > 
> > > 
> 
> 
> 

Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text

[Stefano Stabellini]

On Fri, 6 Jan 2012, Andrew Jones wrote:
> > Almost all of the things which dom0 needs (e.g. PCI device management
> > etc) is also required by a domU with passthrough enabled so the
> > savings
> > are really very slight.
> > 
> > We are talking less than 1k of code AFAICT, 319 bytes for
> > arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
> > whatever xen_register_gsi (a couple of dozen lines of code) adds to
> > arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
> > anywhere else. What savings do you see in practice from disabling
> > just
> > this symbol?
> 
> I completely agree that the saving are near none. The savings, however,
> aren't the only reason to drive the change. It's actually the symbol
> name itself. Unfortunately configs can be perceived as a contract of
> support, i.e. if feature xyz is enabled in the distro's config, then
> the distributor must have selected, and therefore will support, said
> feature.
> 
> I didn't make this motivation clear in my initial post, because I was
> hoping to spare people some eye rolling.

I thought that in the kernel community we make decisions based on
technical merits rather than "contracts of support". 
Given that disabling the symbol saves near to nothing, the logical thing
to do is removing the symbol altogether.

Re: [PATCH 3/4] xen kconfig: add dom0 support help text

[Andrew Jones]

----- Original Message -----
> On Fri, 6 Jan 2012, Andrew Jones wrote:
> > > Almost all of the things which dom0 needs (e.g. PCI device
> > > management
> > > etc) is also required by a domU with passthrough enabled so the
> > > savings
> > > are really very slight.
> > > 
> > > We are talking less than 1k of code AFAICT, 319 bytes for
> > > arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
> > > whatever xen_register_gsi (a couple of dozen lines of code) adds
> > > to
> > > arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
> > > anywhere else. What savings do you see in practice from disabling
> > > just
> > > this symbol?
> > 
> > I completely agree that the saving are near none. The savings,
> > however,
> > aren't the only reason to drive the change. It's actually the
> > symbol
> > name itself. Unfortunately configs can be perceived as a contract
> > of
> > support, i.e. if feature xyz is enabled in the distro's config,
> > then
> > the distributor must have selected, and therefore will support,
> > said
> > feature.
> > 
> > I didn't make this motivation clear in my initial post, because I
> > was
> > hoping to spare people some eye rolling.
> 
> I thought that in the kernel community we make decisions based on
> technical merits rather than "contracts of support".

Sorry.

> Given that disabling the symbol saves near to nothing, the logical
> thing
> to do is removing the symbol altogether.
> 

I thought of that too. If the symbol just goes away, then my
non-technical requirement will be met and the functionality will
stay. I consider that a bigger win actually. I didn't suggest it
though, since I've never done any dom0 development, nor had any
consideration for dom0 code needs of the future. With
anti-credentials like that, I'd guess it'd be tougher for me to sell
the need to remove it, than it is for me to just make it
configurable.

Drew

Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text

[Stefano Stabellini]

On Fri, 6 Jan 2012, Andrew Jones wrote:
> ----- Original Message -----
> > On Fri, 6 Jan 2012, Andrew Jones wrote:
> > > > Almost all of the things which dom0 needs (e.g. PCI device
> > > > management
> > > > etc) is also required by a domU with passthrough enabled so the
> > > > savings
> > > > are really very slight.
> > > > 
> > > > We are talking less than 1k of code AFAICT, 319 bytes for
> > > > arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
> > > > whatever xen_register_gsi (a couple of dozen lines of code) adds
> > > > to
> > > > arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
> > > > anywhere else. What savings do you see in practice from disabling
> > > > just
> > > > this symbol?
> > > 
> > > I completely agree that the saving are near none. The savings,
> > > however,
> > > aren't the only reason to drive the change. It's actually the
> > > symbol
> > > name itself. Unfortunately configs can be perceived as a contract
> > > of
> > > support, i.e. if feature xyz is enabled in the distro's config,
> > > then
> > > the distributor must have selected, and therefore will support,
> > > said
> > > feature.
> > > 
> > > I didn't make this motivation clear in my initial post, because I
> > > was
> > > hoping to spare people some eye rolling.
> > 
> > I thought that in the kernel community we make decisions based on
> > technical merits rather than "contracts of support".
> 
> Sorry.
> 
> > Given that disabling the symbol saves near to nothing, the logical
> > thing
> > to do is removing the symbol altogether.
> > 
> 
> I thought of that too. If the symbol just goes away, then my
> non-technical requirement will be met and the functionality will
> stay. I consider that a bigger win actually. I didn't suggest it
> though, since I've never done any dom0 development, nor had any
> consideration for dom0 code needs of the future. With
> anti-credentials like that, I'd guess it'd be tougher for me to sell
> the need to remove it, than it is for me to just make it
> configurable.
 
The reason to remove is easy: it is already a silent option and
disabling it saves almost nothing.
I think that removing it should be easy enough but if you don't
feel confident doing it, I can come up with a patch.

Re: [PATCH 3/4] xen kconfig: add dom0 support help text

[Andrew Jones]

----- Original Message -----
> On Fri, 6 Jan 2012, Andrew Jones wrote:
> > ----- Original Message -----
> > > On Fri, 6 Jan 2012, Andrew Jones wrote:
> > > > > Almost all of the things which dom0 needs (e.g. PCI device
> > > > > management
> > > > > etc) is also required by a domU with passthrough enabled so
> > > > > the
> > > > > savings
> > > > > are really very slight.
> > > > > 
> > > > > We are talking less than 1k of code AFAICT, 319 bytes for
> > > > > arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o
> > > > > plus
> > > > > whatever xen_register_gsi (a couple of dozen lines of code)
> > > > > adds
> > > > > to
> > > > > arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being
> > > > > used
> > > > > anywhere else. What savings do you see in practice from
> > > > > disabling
> > > > > just
> > > > > this symbol?
> > > > 
> > > > I completely agree that the saving are near none. The savings,
> > > > however,
> > > > aren't the only reason to drive the change. It's actually the
> > > > symbol
> > > > name itself. Unfortunately configs can be perceived as a
> > > > contract
> > > > of
> > > > support, i.e. if feature xyz is enabled in the distro's config,
> > > > then
> > > > the distributor must have selected, and therefore will support,
> > > > said
> > > > feature.
> > > > 
> > > > I didn't make this motivation clear in my initial post, because
> > > > I
> > > > was
> > > > hoping to spare people some eye rolling.
> > > 
> > > I thought that in the kernel community we make decisions based on
> > > technical merits rather than "contracts of support".
> > 
> > Sorry.
> > 
> > > Given that disabling the symbol saves near to nothing, the
> > > logical
> > > thing
> > > to do is removing the symbol altogether.
> > > 
> > 
> > I thought of that too. If the symbol just goes away, then my
> > non-technical requirement will be met and the functionality will
> > stay. I consider that a bigger win actually. I didn't suggest it
> > though, since I've never done any dom0 development, nor had any
> > consideration for dom0 code needs of the future. With
> > anti-credentials like that, I'd guess it'd be tougher for me to
> > sell
> > the need to remove it, than it is for me to just make it
> > configurable.
>  
> The reason to remove is easy: it is already a silent option and
> disabling it saves almost nothing.
> I think that removing it should be easy enough but if you don't
> feel confident doing it, I can come up with a patch.
> 

I'll write the patch. It's not the patch I thought would be hard to
do (although I'll only be posting it compile tested, as I don't
have an environment where I can test it set up). What I thought would
be difficult is the justification. However, considering you're
advocating it, I guess I'm good there too.

Drew

Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text

[Konrad Rzeszutek Wilk]

> > The reason to remove is easy: it is already a silent option and
> > disabling it saves almost nothing.
> > I think that removing it should be easy enough but if you don't
> > feel confident doing it, I can come up with a patch.
> > 
> 
> I'll write the patch. It's not the patch I thought would be hard to
> do (although I'll only be posting it compile tested, as I don't
> have an environment where I can test it set up). What I thought would

Um.. Fedora Core 16?

> be difficult is the justification. However, considering you're
> advocating it, I guess I'm good there too.

We don't bite :-)

[PATCH 4/4] xen kconfig: describe xen tmem in the config menu

[Andrew Jones]

Add a description to the config menu for xen tmem.
---
 drivers/xen/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 1d24061..7e8d728 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -143,7 +143,7 @@ config SWIOTLB_XEN
 	select SWIOTLB
 
 config XEN_TMEM
-	bool
+	bool "Xen Transcendent Memory (tmem)"
 	default y if (CLEANCACHE || FRONTSWAP)
 	help
 	  Shim to interface in-kernel Transcendent Memory hooks
-- 
1.7.7.5

[PATCH 0/4] xen kconfig tweaks

[Andrew Jones]

This series is a collection of xen kconfig fixes and additions.

Andrew Jones (4):
  xen kconfig: keep XEN_XENBUS_FRONTEND builtin
  xen kconfig: relax INPUT_XEN_KBDDEV_FRONTEND deps
  xen kconfig: add dom0 support help text
  xen kconfig: describe xen tmem in the config menu

 arch/x86/xen/Kconfig       |    7 ++++++-
 drivers/input/misc/Kconfig |    2 +-
 drivers/video/Kconfig      |    1 +
 drivers/xen/Kconfig        |    4 ++--
 4 files changed, 10 insertions(+), 4 deletions(-)

-- 
1.7.7.5

[PATCH 3/4] xen kconfig: add dom0 support help text

[Andrew Jones]

Describe dom0 support in the config menu and supply help text for it.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 arch/x86/xen/Kconfig |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 26c731a..88862d5 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -14,9 +14,14 @@ config XEN
 	  Xen hypervisor.
 
 config XEN_DOM0
-	def_bool y
+	bool "Xen Initial Domain (Dom0) support"
+	default y
 	depends on XEN && PCI_XEN && SWIOTLB_XEN
 	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
+	help
+	  This allows the kernel to be used for the initial Xen domain,
+	  Domain0. This is a privileged guest that supplies backends
+	  and is used to manage the other Xen domains.
 
 # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
 # name in tools.
-- 
1.7.7.5

Re: [PATCH 3/4] xen kconfig: add dom0 support help text

[Konrad Rzeszutek Wilk]

On Fri, Jan 06, 2012 at 10:43:10AM +0100, Andrew Jones wrote:
> Describe dom0 support in the config menu and supply help text for it.

So I had this reply in my draft and forgot to send it. Sorry about that.

My understanding from the converstion was that we try to "squash"
the XEN_DOM0 option so that it would not be present. But that did not
work as it lead to a string of X86_LOCAL_APIC, X86_IO_ACPI, ACPI, PCI,
and so on. Then the .h with #define XEN_something based on those
symbols, but that is not the job of a header file. It is the job
of Kconfig.

The other way was to squash this in with the backend support. Since
we are moving away from having one initial domain, to having
multitple "initial domains" (priviliged domains) where each can
server as a backend.  However (quoting Jeremy) "it is more of
disaggregating the privilege to reduce the amount concentrated in any one
part.  Backends don't need any more privilege than to be able to
access the specific device(s) they're being the backend for."

Interestingly, that means DOM0 is kind of .. well, it should be
no different from a normal HVM guest. The old-style PV dom0 remains
would be ..well, almost nothing. The Xen MMU, and Xen SWIOTLB - those
are the ones that pop in mind for Dom0, but they are also used
for PV PCI. In fact, all (I think?) of the CONFIG_XEN_DOM0 functionality
can be _used_ in a PV guest. The 'if (initial_xen_domain()' should
probably be addressed first and to figure which one of those can be
altered as the "backend domain" can run both frontend and backend drivers
(oh joy!). So more relaxing those config options and/or "if (xen..)".

Anyhow, back to the HVM dom0 - that is in the future - and it is going
to take a couple of years to get it. I would rather not shoot my
foot by removing these CONFIG_* option until we get a better grasp of how
we want to deal with the PV hybrid.

What I am saying is that I don't know what the right answer is,
but I don't believe the patch below is it. I wish I had a better
answer in terms of "do this instead", but none of those worked.

Perhaps we can brainstorm some of this at XenSummit by which time
I hope Mukesh's PV hybrid work will be completed and a lot of the
work on the toolstack for backend drivers will be laid out.

> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  arch/x86/xen/Kconfig |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 26c731a..88862d5 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -14,9 +14,14 @@ config XEN
>  	  Xen hypervisor.
>  
>  config XEN_DOM0
> -	def_bool y
> +	bool "Xen Initial Domain (Dom0) support"
> +	default y
>  	depends on XEN && PCI_XEN && SWIOTLB_XEN
>  	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> +	help
> +	  This allows the kernel to be used for the initial Xen domain,
> +	  Domain0. This is a privileged guest that supplies backends
> +	  and is used to manage the other Xen domains.
>  
>  # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
>  # name in tools.
> -- 
> 1.7.7.5