Group all the "guest OS" support options together, under

CONFIG_PARAVIRT.  Make this a proper menu item so it looks neater on

menuconfig etc, and make the wording for each prompt uniform.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff -r 3d3ac181380b arch/i386/Kconfig

--- a/arch/i386/Kconfig	Fri Sep 14 12:24:15 2007 +1000

+++ b/arch/i386/Kconfig	Fri Sep 14 12:45:09 2007 +1000

@@ -214,28 +214,38 @@ config X86_ES7000
 endchoice
-config PARAVIRT

-	bool "Paravirtualization support (EXPERIMENTAL)"

+menuconfig PARAVIRT

+	bool "Paravirtualized guest support (EXPERIMENTAL)"

 	depends on EXPERIMENTAL

 	depends on !(X86_VISWS || X86_VOYAGER)

 	help

 	  Paravirtualization is a way of running multiple instances of

 	  Linux on the same machine, under a hypervisor.  This option

 	  changes the kernel so it can modify itself when it is run

 	  under a hypervisor, improving performance significantly.

 	  However, when run without a hypervisor the kernel is

 	  theoretically slower.  If in doubt, say N.

+

+if PARAVIRT
 source "arch/i386/xen/Kconfig"
 config VMI

-	bool "VMI Paravirt-ops support"

-	depends on PARAVIRT

+	bool "VMI Guest support"

 	help

 	  VMI provides a paravirtualized interface to the VMware ESX server

 	  (it could be used by other hypervisors in theory too, but is not

 	  at the moment), by linking the kernel to a GPL-ed ROM module

 	  provided by the hypervisor.

+

+config LGUEST_GUEST

+	bool "Lguest guest support"

+	depends on !X86_PAE

+	help

+	  Lguest is a tiny in-kernel hypervisor.  Selecting this will

+	  allow your kernel to boot under lguest.  This option will increase

+	  your kernel size by about 6k.  If in doubt, say N.

+endif
 config ACPI_SRAT

 	bool

diff -r 3d3ac181380b arch/i386/xen/Kconfig

--- a/arch/i386/xen/Kconfig	Fri Sep 14 12:24:15 2007 +1000

+++ b/arch/i386/xen/Kconfig	Fri Sep 14 12:37:38 2007 +1000

@@ -3,8 +3,8 @@

 #
 config XEN

-	bool "Enable support for Xen hypervisor"

-	depends on PARAVIRT &&am...
[ message continues ]

We turn "Virtualization" into a menu, not a config option, since it's

actually only used as a menu.  Then we move lguest under that menu.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff -r c2893801de2a drivers/Kconfig

--- a/drivers/Kconfig	Fri Sep 14 13:24:46 2007 +1000

+++ b/drivers/Kconfig	Fri Sep 14 13:24:49 2007 +1000

@@ -87,6 +87,4 @@ source "drivers/kvm/Kconfig"

 source "drivers/kvm/Kconfig"
 source "drivers/uio/Kconfig"

-

-source "drivers/lguest/Kconfig"

 endmenu

diff -r c2893801de2a drivers/kvm/Kconfig

--- a/drivers/kvm/Kconfig	Fri Sep 14 13:24:46 2007 +1000

+++ b/drivers/kvm/Kconfig	Fri Sep 14 13:32:22 2007 +1000

@@ -1,21 +1,12 @@

 #

 # KVM configuration

 #

-menuconfig VIRTUALIZATION

-	bool "Virtualization"

+menu "Virtualization"

 	depends on X86

-	default y

-	---help---

-	  Say Y here to get to see options for virtualization guest drivers.

-	  This option alone does not add any kernel code.

-

-	  If you say N, all options in this submenu will be skipped and disabled.

-

-if VIRTUALIZATION
 config KVM

 	tristate "Kernel-based Virtual Machine (KVM) support"

-	depends on X86 && EXPERIMENTAL

+	depends on EXPERIMENTAL

 	select ANON_INODES

 	---help---

 	  Support hosting fully virtualized guest machines using hardware

@@ -45,4 +36,8 @@ config KVM_AMD

 	  Provides support for KVM on AMD processors equipped with the AMD-V

 	  (SVM) extensions.
-endif # VIRTUALIZATION

+# OK, it's a little counter-intuitive to do this, but it puts it neatly under

+# the virtualization menu.

+source drivers/lguest/Kconfig

+

+endmenu
-

so you want to revert the 2007-july-16 merge that changes

menu -> menuconfig and makes most of the menus consistent in

presentation.  I'd rather not, but I don't own it.
---

~Randy

*** Remember to use Documentation/SubmitChecklist when testing your code ***

-

Ok, I missed that one.  To me it seems gratuitous to create a config

option simply to control a menu.  However if that is considered the
Indeed,

Rusty.

===

Move lguest under the virtualization menu.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff -r c2893801de2a drivers/Kconfig

--- a/drivers/Kconfig	Fri Sep 14 13:24:46 2007 +1000

+++ b/drivers/Kconfig	Fri Sep 14 13:24:49 2007 +1000

@@ -87,6 +87,4 @@ source "drivers/kvm/Kconfig"

 source "drivers/kvm/Kconfig"
 source "drivers/uio/Kconfig"

-

-source "drivers/lguest/Kconfig"

 endmenu

diff -r c2893801de2a drivers/kvm/Kconfig

--- a/drivers/kvm/Kconfig	Fri Sep 14 13:24:46 2007 +1000

+++ b/drivers/kvm/Kconfig	Fri Sep 14 13:32:22 2007 +1000

@@ -45,4 +36,8 @@ config KVM_AMD

 	  Provides support for KVM on AMD processors equipped with the AMD-V

 	  (SVM) extensions.
-endif # VIRTUALIZATION

+# OK, it's a little counter-intuitive to do this, but it puts it neatly under

+# the virtualization menu.

+source drivers/lguest/Kconfig

+

+endif # VIRTUALIZATION
-

What about containerization bits ?
IPC_Namespaces, *_Namespaces  - I think we should evaluate adding them

too to this menu.
--

-Alexey Eremenko "Technologov"

-

Well, containerization deserves its own menu, but the question is does i

it belong under this menu?
Rusty.
-

No, I don't think so.  While there are some broad similarities in

effect, the technology is completely different, as are the capabilities

and tradeoffs.  They're pretty much orthogonal.
    J

-

It seems to me containerization is much more similar a feature to SYSV

IPC, process accounting / auditing, and should be an option under

General setup, possibly with its own submenu.  Nearly all the features

under general setup provide optional extensions to kernel services

available from userspace, and so it seems containerization falls

naturally into that category.
Virtualization is completely different, and probably needs separate

server (kvm, lguest) and client (kvm, lguest, xen, vmware) sections in

it's menu.
Zach
-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
Zachary Amsden wrote:
So what is the differentiation between client and server above? Just

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.6 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG7w3ckQPZV56XDBMRAvvaAJ9cHl+A321MJyw6W4J4yIDurz0K2wCcDg8J

uOR6alAGvWjxEbThiuaeIDc=

=TQ3m

-----END PGP SIGNATURE-----

-

"Host" and "guest" are better terms, I think.  Kvm is all host, since

guests need no modification.  lguest turns the kernel into both host and

guest.  Xen Linux kernels are all guest, since the Xen hypervisor is the

host.
    J

-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.6 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD4DBQFG8DDdkQPZV56XDBMRAl6NAJ90z7tRO+xAvbOOkKeKH6LZWGjNSACYms3u

dqGGgl1GOFraS08UmEf++A==

=HgFC

-----END PGP SIGNATURE-----

-

Yes, I also prefer terms like "Host" and "Guest". Those terms are more

correct than "Server" and "Client", which are often reffered to

TCP/UDP port listening and network connection.
--

-Alexey Eremenko "Technologov"

-

Whatever, keep it as menuconfig. I want to disable it _at once_

without having to enter the menu, which is the primary motivation

having it as 'menuconfig'.
	Jan

--

-

It's pretty widely used, and the distributions will turn it on.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> 
diff -r b546335d7e75 arch/i386/Kconfig

--- a/arch/i386/Kconfig	Fri Sep 14 13:24:49 2007 +1000

+++ b/arch/i386/Kconfig	Fri Sep 14 13:27:13 2007 +1000

@@ -215,8 +215,8 @@ endchoice

 endchoice
 menuconfig PARAVIRT

-	bool "Paravirtualized guest support (EXPERIMENTAL)"

-	depends on EXPERIMENTAL

+	bool "Paravirtualized guest support"

+	default y

 	depends on !(X86_VISWS || X86_VOYAGER)

 	help

 	  Paravirtualization is a way of running multiple instances of

@@ -224,7 +224,7 @@ menuconfig PARAVIRT

 	  changes the kernel so it can modify itself when it is run

 	  under a hypervisor, improving performance significantly.

 	  However, when run without a hypervisor the kernel is

-	  theoretically slower.  If in doubt, say N.

+	  theoretically slower.  If in doubt, say Y.
 if PARAVIRT
-

That's no reason to make it default y. Please undo that. default y

is near always a bad idea.
Also I would still consider it experimental.
-Andi

-

Hi Andi,
	Please stop asking for facts!  It's was easy claim to make, and hard to
How about a "select" based on Xen, lguest or VMI?  There's no other
After 9 months in mainline and three kernel versions, I'd hope not.

It's been pretty damn stable (ok, you broke it once, but maybe that's

because you consider it experimental).
Cheers,

Rusty.
-

I did an patch to do that recently because  the current setup

is indeed unobvious.
But I had to drop it again because

it ended up with Kconfig warnings. about undefined symbols

on x86-64. The problem is that lguest

is visible in Kconfig for all architectures and it warns

if you select something that doesn't exist on all architectures.
The only workaround would have been to define PARAVIRT

for all architectures, which I considered too ugly.
I think Sam stated recently he wanted to remove that warning
Is there a significant user base? 
At least the Xen port seems to have specific requirements

and essentially only work on xen-unstable (?) [or at least

some very new Xen version] which probably very few

people use.
-Andi
-

Only on 64-bit hosts, because of bugs in the 64-bit compat layer.

32-on-32 and 64-on-64 (when its done) should work fine.
BTW, what does "xm info" say on your system that fails?  I'll try to put

a more graceful failure in there.
    J

-

All the required fixes for 32on64 are queued for Xen 3.1.1 too. The

proposed updates are at

http://xenbits.xensource.com/xen-3.1-testing.pq.hg
Ian.
--

Ian Campbell

Current Noise: Detonation - Sword-Carved Skin
The executioner is, I hear, very expert, and my neck is very slender.

		-- Anne Boleyn
-

I think that's fixed as a side-effect of this cleanup.  At least, it

works for me on x86-64.  Patch below: if you agree, I'll re-xmit all
Well, the biggest change was the patching code getting enhanced in

2.6.22 (to cover all calls, not just 5).  The 22 -> 23 changes were

fairly trivial.
Sure, and that might well still be experimental (Jeremy?).  But that's

not CONFIG_PARAVIRT.
Hope that helps,

Rusty.

==

Andi points out that PARAVIRT is an option best selected when needed.
We introduce PARAVIRT_GUEST for the menu itself, and select PARAVIRT

if they ask for anything which needs it.  This also makes PARAVIRT

non-experimental.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff -r 8efa5fdb22d8 arch/i386/Kconfig

--- a/arch/i386/Kconfig	Wed Sep 19 11:23:18 2007 +1000

+++ b/arch/i386/Kconfig	Wed Sep 19 11:33:59 2007 +1000

@@ -214,24 +214,30 @@ config X86_ES7000
 endchoice
-menuconfig PARAVIRT

+config PARAVIRT

+	bool

+	depends on !(X86_VISWS || X86_VOYAGER)

+	help

+	  This changes the kernel so it can modify itself when it is run

+	  under a hypervisor, potentially improving performance significantly

+	  over full virtualization.  However, when run without a hypervisor

+	  the kernel is theoretically slower and slightly larger.

+

+menuconfig PARAVIRT_GUEST

-	bool "Paravirtualized guest support (EXPERIMENTAL)"

-	depends on EXPERIMENTAL

+	bool "Paravirtualized guest support"

-	depends on !(X86_VISWS || X86_VOYAGER)

-	help

-	  Paravirtualization is a way of running multiple instances of

-	  Linux on the same machine, under a hypervisor.  This option

-	  changes the kernel so it can modify itself when it is run

-	  under a hypervisor, improving performance significantly.

-	  However, when run without a hypervisor the kernel is

-	  theoretically slower.  If in doubt, say N.

-

-if PARAVIRT

+	help

+	  Say Y here to get to see options related to running Linux under

+	  various hypervisors.  This option alone does not add any kernel code.

+

+	...
[ message continues ]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
Andi,
	What do you base this on? Why is making something default y a bad idea?

Those most likely to care can turn it off. Is there a harmful effect

from leaving it on if its not being used?
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.6 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG8C9QkQPZV56XDBMRAowcAJ9fkxKAjjsvGd6hOPkvHXU9ThpoQwCdGUI8

mjpUh6G+ZyzL0CW3sYNS97g=

=ZgiJ

-----END PGP SIGNATURE-----

-

Running yes "" | make oldconfig to upgrade kernel configs is standard practice

and you definitely don't want to have all kinds of random new unnecessary features

be turned on then.
Besides paravirt by itself is pretty useless; you need typically quite

complex other options set to do any meaningfull virtualization.
The only reason to use default y is in options that are not user visible

and have a reasonable default or things that cause direct boot failures

when upgrading old configurations. That all doesn't apply here.
Besides it's bad taste and taste is very important.
-Andi

-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
Hmmmm. I disagree its a standard practice. I thought the whole point of

make oldconfig was to give you just the delta in configuration options

and was targeted at manual review?
Also how many people are building there own kernels these days?

Expanding on what I said in the original e-mail those who are likely to

care "CAN TURN IT OFF". Those who care about such things should be

REVIEWING CHANGES anyway. Thats what I do when looking at building

custom kernels. What changed that makes me want to move to a new version?
I generally try to stick with the distro kernel when possible, but part

of being an early and aggressive adopter of virtualization technology

involves running non distro kernels and patches.
Actually if I understand the functionality of paravirt correctly that is

not correct. I believe that will turn on the paravirt bits which allow
Again you need to think about the target audience here. A distro kernel

you don't have to worry about this stuff. A user compiling there own
Well it's bad taste for you (one person). Taste is highly subjective. So

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.6 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG8DSnkQPZV56XDBMRAtZcAJ4rtRXGW14b70YRIBKyHCsaKTdO/wCeOdoM

AUc4YGUaqs5DmDDbov7X980=

=UA4y

-----END PGP SIGNATURE-----

-

FWIW, my opinion is the same as Andi's here. Please, let's avoid this

disease -- unless *absolutely* required, stuff shouldn't be "default y".

-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
I am curious why you think it shouldn't be default why? Bad taste? Can

you provide data about how it will harm things?
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.6 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG8ptLkQPZV56XDBMRApxNAJwLOv2dabO6KD6t4Z/Fkffelh1IxwCdEzPM

1JEuIQvlkiojgiMy0tnroqk=

=yCiZ

-----END PGP SIGNATURE-----

-

Clear CONFIG_PARAVIRT from your .config and try "make oldconfig", and find

out for yourself :-)
You'll end up having to answer questions for all other config options

below it, that you never cared about, that you didn't know even existed.

You'd obviously (I would, at least) feel annoyed by it all ... this is

almost a regression :-)
And for those who automate the oldconfig process using "yes", well, this

"default y" *will* end up introducing a kernel text size regression --

all those config options they never had earlier, suddenly got enabled.
Besides, like Andi said, selecting or enabling CONFIG_PARAVIRT is quite

pointless in the first place -- it's just a menuconfig symbol, not a

"real" kconfig symbol that _actually_ controls code in the Makefiles.
Satyam

-

You don't understand it correctly then.
-Andi

-