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

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 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

Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option

[Konrad Rzeszutek Wilk]

> > If the root complaint is that "customers think that anything set in
> > .config is a supported feature", then the solutions are to support
> > all
> > the features in .config, re-educate the customers that they're wrong,
> > or
> > maintain a local patch to do this stuff.
> 
> If only re-educating people was free, like preempting questions is.
> Local patches are of course always an option, and perhaps in this
> case it's the best one. However, I think we already made a case for
> better xen configurability for the driver domains, so I'm not 100%

Could you repost those backend patches please? At this point I am not
sure which one we have discarded?

> convinced my initial patch (making dom0 configurable) isn't worthy
> of upstream. Also, I didn't see any comments on my v2[*] of that
> patch, which I believe satisfies the menu complexity issue and
> brings in more configurability. That said, I'm about to reply to
> that patch myself, since there's an issue with it.
> 
> Drew
> 
> [*] http://article.gmane.org/gmane.linux.kernel.virtualization/14635
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 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

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

[Konrad Rzeszutek Wilk]

On Wed, Jan 11, 2012 at 05:36:38PM +0100, Andrew Jones wrote:
> 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.

Hm, don't the frontends by themsevles load this module? So if you
do 'modprobe xen-pcifront' it would load this automatically?

> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  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

Re: [Xen-devel] [PATCH 1/4] xen kconfig: keep XEN_XENBUS_FRONTEND builtin

[Andrew Jones]

----- Original Message -----
> On Wed, Jan 11, 2012 at 05:36:38PM +0100, Andrew Jones wrote:
> > 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.
> 
> Hm, don't the frontends by themsevles load this module? So if you
> do 'modprobe xen-pcifront' it would load this automatically?
> 

The problem is on boot, getting it there before we need xen-blkfront.
I think it might solvable if you make sure your tooling pushes the
xenbus module into your initrd. However we've had problems with
platform_pci being a module in the past, and if I'm not mistaken
that was one of the motivators for building it in (5fbdc10395cd). I
see this as a similar story.

Drew

> > 
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> >  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
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

Re: [Xen-devel] [PATCH 1/4] xen kconfig: keep XEN_XENBUS_FRONTEND builtin

[Konrad Rzeszutek Wilk]

On Thu, Jan 12, 2012 at 05:49:57AM -0500, Andrew Jones wrote:
> 
> 
> ----- Original Message -----
> > On Wed, Jan 11, 2012 at 05:36:38PM +0100, Andrew Jones wrote:
> > > 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.
> > 
> > Hm, don't the frontends by themsevles load this module? So if you
> > do 'modprobe xen-pcifront' it would load this automatically?
> > 
> 
> The problem is on boot, getting it there before we need xen-blkfront.
> I think it might solvable if you make sure your tooling pushes the
> xenbus module into your initrd. However we've had problems with

So it seems we also need patches for dracut and initramfs here?

Or is it possible to make the modules (fb) try to load xenbus frontend
automatically? Preferrably one would do this:

modprobe xen_fbfront
which would then automatically load xenbus_module, xen_kbdfront

Better yet if udev/kudzu figured out this automtically and loaded
the modules.

Is there a mechanism to automatically have udev do all of this loading?
Let CC the Debian maintainer on this converstation as he might have
some ideas in this.


> platform_pci being a module in the past, and if I'm not mistaken

Right, but that driver is not tied in with the frontends. It just
pokes at the ioport to disable QEMU HVM drivers.

> that was one of the motivators for building it in (5fbdc10395cd). I
> see this as a similar story.
> 
> Drew
> 
> > > 
> > > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > > ---
> > >  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
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> > 

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

[Bastian Blank]

On Thu, Jan 12, 2012 at 09:37:45AM -0500, Konrad Rzeszutek Wilk wrote:
> Or is it possible to make the modules (fb) try to load xenbus frontend
> automatically? Preferrably one would do this:

Which modules?

> modprobe xen_fbfront
> which would then automatically load xenbus_module, xen_kbdfront

I think you are missing something.

| video/xen-fbfront.c:      return xenbus_register_frontend(&xenfb_driver);
| xen/xenbus/xenbus_probe_frontend.c:EXPORT_SYMBOL_GPL(xenbus_register_frontend);

xen-fbfront already pulls in the module, at least in Linus' tree.

> Better yet if udev/kudzu figured out this automtically and loaded
> the modules.

No workarounds for kernel problems if not absolutely necessary.

Bastian

-- 
Military secrets are the most fleeting of all.
		-- Spock, "The Enterprise Incident", stardate 5027.4