Re: [patch 14/21] Xen-paravirt: Add XEN config options and disableunsupported config options.

From: Dan Hecht
Date: Fri Feb 16 2007 - 01:15:43 EST

On 02/15/2007 06:25 PM, Jeremy Fitzhardinge wrote:
The XEN config option enables the Xen paravirt_ops interface, which is
installed when the kernel finds itself running under Xen. (By some
as-yet fully defined mechanism, implemented in a future patch.)

Xen is no longer a sub-architecture, so the X86_XEN subarch config
option has gone.

The disabled config options are:
- PREEMPT: Xen doesn't support it
- HZ: set to 100Hz for now, to cut down on VCPU context switch rate.
This will be adapted to use tickless later.
- kexec: not yet supported

config KEXEC
bool "kexec system call"
+ depends on !XEN
kexec is a system call that implements the ability to shutdown your
current kernel, and to start another kernel. It is like a reboot

default y
bool "Enable doublefault exception handler" if EMBEDDED
+ depends on !XEN
This option allows trapping of rare doublefault exceptions that
would otherwise cause a system to silently reboot. Disabling this

+config XEN
+ bool "Enable support for Xen hypervisor"
+ depends PARAVIRT
+ default y
+ help
+ This is the Linux Xen port.

- prompt "Timer frequency"
+ prompt "Timer frequency" if !XEN
default HZ_250
Allows the configuration of the timer frequency. It is customary
@@ -49,7 +49,7 @@ endchoice
config HZ
- default 100 if HZ_100
+ default 100 if HZ_100 || XEN
default 250 if HZ_250
default 300 if HZ_300
default 1000 if HZ_1000

config PREEMPT
bool "Preemptible Kernel (Low-Latency Desktop)"
+ depends on !XEN
This option reduces the latency of the kernel by making
all kernel code (that is not executing in a critical section)

I hate to sound like a broken record, but this really isn't the right way to do this. If you are going to inhibit config settings when Xen support is compiled, then it should be:

config XEN
depends on !KEXEC && !DOUBLEFAULT && HZ_100 && !PREEMPT

I'm really not trying to make things more difficult for you or for Xen users.

One of the primary goals of paravirt-ops is to allow the same kernel binary to bind to multiple hypervisor interfaces (and native), at runtime. So, we should assume that kernels which are built with CONFIG_PARAVIRT will also enable all the paravirt-ops backends; and this is a good thing.

But, the problem is, then, when someone enables paravirt (and all the backends, including Xen), you are silently forcing all these options off. Compiling in paravirt support should not change force you into using some set of config option; when a paravirt-ops kernel is run on native, it should be as fully featured as a non-paravirtops kernel.

So, this should really be solved (in order of preference) by:

1) Complete the xen paravirt-ops backend so it can handle these "incompatible" options. I realize this is just a matter of time (at least for most of them, what is your plan for PREEMPT?).

2) Disable the option at runtime only if the kernel is booted on Xen. When the kernel is booted on native, lhype, paravirt kvm, vmware, etc it should be not be inhibited. This may not be feasible for all of these options, but as Zach pointed out, is easy enough for DOUBLEFAULT. Maybe it can be done for KEXEC? And HZ is easy to allow too, even though Xen will still give interrupts at 100hz -- we do this when you boot on VMI. PREEMPT is probably the only real compile time incompatible options with Xen. You just simply have to change the loop decrementors in your timer interrupt.

You basically chose #2 for SMP: while your backend doesn't support it yet, it's not harmful to have the config option enabled; you just don't allow a second vcpu to startup when running on Xen.

3) Use the config XEN line I suggest above. The net effect is the same as your proposed change (it prevents users from compiling the incompatible options together), but at least the user understands what is going on, instead of options just silently changing on them.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at