Jeremy,
CONFIG_XEN (in 2.6.23) depends on X86_CMPXCHG and X86_TSC. This
precludes enabling the option in kernels using M386, M486, or M586, despite
the fact that the detection code doesn't need these features and if Xen is
present the features are implicitly there. At least the X86_TSC dependency
can thus be dropped in my opinion, which would then only exclude M386
kernels. (Dropping X86_CMPXCHG may yield build problems, but could
perhaps also be eliminated by forcibly #define-ing it in the relevant source
files.)
Jan
Jan Beulich wrote:
> Jeremy,
>
> CONFIG_XEN (in 2.6.23) depends on X86_CMPXCHG and X86_TSC. This
> precludes enabling the option in kernels using M386, M486, or M586, despite
> the fact that the detection code doesn't need these features and if Xen is
> present the features are implicitly there. At least the X86_TSC dependency
> can thus be dropped in my opinion, which would then only exclude M386
> kernels. (Dropping X86_CMPXCHG may yield build problems, but could
> perhaps also be eliminated by forcibly #define-ing it in the relevant source
> files.)
Yeah, that's a bit tacky though. We added it because reviewers
(probably Adrian Bunk, or maybe akpm) noticed the Xen code
unconditionally using cmpxchg, and I added tsc because, well, we use it.
But you're right; we can't get to any of the Xen code without booting
under Xen, which necessarily means all those features are available,
regardless of how the kernel is configured.
What config combinations do you want to support?
J
>>> Jeremy Fitzhardinge <[email protected]> 23.10.07 20:09 >>>
>Jan Beulich wrote:
>> Jeremy,
>>
>> CONFIG_XEN (in 2.6.23) depends on X86_CMPXCHG and X86_TSC. This
>> precludes enabling the option in kernels using M386, M486, or M586, despite
>> the fact that the detection code doesn't need these features and if Xen is
>> present the features are implicitly there. At least the X86_TSC dependency
>> can thus be dropped in my opinion, which would then only exclude M386
>> kernels. (Dropping X86_CMPXCHG may yield build problems, but could
>> perhaps also be eliminated by forcibly #define-ing it in the relevant source
>> files.)
>
>Yeah, that's a bit tacky though. We added it because reviewers
>(probably Adrian Bunk, or maybe akpm) noticed the Xen code
>unconditionally using cmpxchg, and I added tsc because, well, we use it.
>
>But you're right; we can't get to any of the Xen code without booting
>under Xen, which necessarily means all those features are available,
>regardless of how the kernel is configured.
>
>What config combinations do you want to support?
The specific goal is to be able to enable the XEN option in our native kernel,
which gets configured with M586. So we could live with XEN depending on
X86_CMPXCHG, but would definitely need the dependency on X86_TSC
dropped. Nevertheless I'd favor even X86_CMPXCHG dropped unless that
causes unresolvable (or difficult to resolve) problems.
Jan
Jan Beulich wrote:
> The specific goal is to be able to enable the XEN option in our native kernel,
> which gets configured with M586. So we could live with XEN depending on
> X86_CMPXCHG, but would definitely need the dependency on X86_TSC
> dropped. Nevertheless I'd favor even X86_CMPXCHG dropped unless that
> causes unresolvable (or difficult to resolve) problems.
Seems reasonable. Do you have a patch?
J
On Wed, Oct 24, 2007 at 12:00:43PM -0700, Jeremy Fitzhardinge wrote:
> Jan Beulich wrote:
> > The specific goal is to be able to enable the XEN option in our native kernel,
> > which gets configured with M586. So we could live with XEN depending on
> > X86_CMPXCHG, but would definitely need the dependency on X86_TSC
> > dropped. Nevertheless I'd favor even X86_CMPXCHG dropped unless that
> > causes unresolvable (or difficult to resolve) problems.
>
> Seems reasonable. Do you have a patch?
You might want a runtime check for these features as a future Xen
hypervisor might eliminate these requirements.
Ok, not really likely, but still possible.
--
Mathematics is the supreme nostalgia of our time.
Matt Mackall wrote:
> You might want a runtime check for these features as a future Xen
> hypervisor might eliminate these requirements.
>
> Ok, not really likely, but still possible.
>
Seems pretty unlikely. All existing guests assume cmpxchg is available,
and the hypercall ABI depends on the tsc.
J