[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.999.0707171212070.27353@woody.linux-foundation.org>
Date: Tue, 17 Jul 2007 12:15:06 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "H. Peter Anvin" <hpa@...or.com>
cc: caglar@...dus.org.tr, Avi Kivity <avi@...ranet.com>,
linux-kernel@...r.kernel.org, kvm-devel@...ts.sourceforge.net,
Andi Kleen <andi@...stfloor.org>
Subject: Re: [GIT PULL][RESEND #2] KVM Updates for 2.6.23-rc1
On Tue, 17 Jul 2007, H. Peter Anvin wrote:
>
> S.Çağlar Onur wrote:
> >
> > If i'm not wrong X86_CMPXCHG64 depends on CONFIG_X86_PAE which depends on
> > HIGHMEM64 and again if i'm not wrong this means distributions who wants to
> > provide KVM must enable CONFIG_X86_PAE and CONFIG_HIGHMEM64G from now on?
> >
>
> X86_PAE should depend on X86_CMPXCHG64, not the other way around.
Actually, I think the *real* solution would be:
- add a X86_HAS_CMPXCHG8B config option, and set it for the appropriate
CPU selection (P6 and up, or whatever the rule is)
- make KVM depend on it
- make KVM and HIGHMEM64 _select_ another config option, namely the
NEEDS_CMPXCHG8B
and then we make the cpufeatures code check the CMPXCHG bit only if the
NEEDS_CMPXCHG8B thing is set. That gives us the best of all worlds.
Because there is no point in checking whether the CPU supports it if the
kernel doesn't _need_ it. Especially since we know that some CPU's lie
about it due to old NT bugs.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists