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

[Dan Hecht <dhecht@xxxxxxxxxx>]

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
>         help
>           kexec is a system call that implements the ability to shutdown your
>           current kernel, and to start another kernel.  It is like a reboot
>  config DOUBLEFAULT
>         default y
>         bool "Enable doublefault exception handler" if EMBEDDED
> +       depends on !XEN
>         help
>            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.
>  choice
> -       prompt "Timer frequency"
> +       prompt "Timer frequency" if !XEN
>         default HZ_250
>         help
>          Allows the configuration of the timer frequency. It is customary
> @@ -49,7 +49,7 @@ endchoice
>  
>  config HZ
>         int
> -       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
>         help
>           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.
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel