linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* CONFIG_XEN dependencies
@ 2007-10-23 10:03 Jan Beulich
  2007-10-23 18:09 ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 6+ messages in thread
From: Jan Beulich @ 2007-10-23 10:03 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: linux-kernel

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: CONFIG_XEN dependencies
  2007-10-23 10:03 CONFIG_XEN dependencies Jan Beulich
@ 2007-10-23 18:09 ` Jeremy Fitzhardinge
  2007-10-24  8:31   ` Jan Beulich
  0 siblings, 1 reply; 6+ messages in thread
From: Jeremy Fitzhardinge @ 2007-10-23 18:09 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Linux Kernel Mailing List, Jeremy Fitzhardinge

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: CONFIG_XEN dependencies
  2007-10-23 18:09 ` Jeremy Fitzhardinge
@ 2007-10-24  8:31   ` Jan Beulich
  2007-10-24 19:00     ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 6+ messages in thread
From: Jan Beulich @ 2007-10-24  8:31 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Jeremy Fitzhardinge, Linux Kernel Mailing List

>>> Jeremy Fitzhardinge <jeremy@xensource.com> 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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: CONFIG_XEN dependencies
  2007-10-24  8:31   ` Jan Beulich
@ 2007-10-24 19:00     ` Jeremy Fitzhardinge
  2007-10-24 19:53       ` Matt Mackall
  0 siblings, 1 reply; 6+ messages in thread
From: Jeremy Fitzhardinge @ 2007-10-24 19:00 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Jeremy Fitzhardinge, Linux Kernel Mailing List

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: CONFIG_XEN dependencies
  2007-10-24 19:00     ` Jeremy Fitzhardinge
@ 2007-10-24 19:53       ` Matt Mackall
  2007-10-24 19:56         ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 6+ messages in thread
From: Matt Mackall @ 2007-10-24 19:53 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Jan Beulich, Jeremy Fitzhardinge, Linux Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: CONFIG_XEN dependencies
  2007-10-24 19:53       ` Matt Mackall
@ 2007-10-24 19:56         ` Jeremy Fitzhardinge
  0 siblings, 0 replies; 6+ messages in thread
From: Jeremy Fitzhardinge @ 2007-10-24 19:56 UTC (permalink / raw)
  To: Matt Mackall; +Cc: Jan Beulich, Jeremy Fitzhardinge, Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2007-10-24 19:57 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-10-23 10:03 CONFIG_XEN dependencies Jan Beulich
2007-10-23 18:09 ` Jeremy Fitzhardinge
2007-10-24  8:31   ` Jan Beulich
2007-10-24 19:00     ` Jeremy Fitzhardinge
2007-10-24 19:53       ` Matt Mackall
2007-10-24 19:56         ` Jeremy Fitzhardinge

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).