[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C784DB8.5090105@redhat.com>
Date: Fri, 27 Aug 2010 13:43:52 -1000
From: Zachary Amsden <zamsden@...hat.com>
To: Jan Kiszka <jan.kiszka@...mens.com>
CC: kvm@...r.kernel.org, Avi Kivity <avi@...hat.com>,
Marcelo Tosatti <mtosatti@...hat.com>,
Glauber Costa <glommer@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
John Stultz <johnstul@...ibm.com>, linux-kernel@...r.kernel.org
Subject: Re: [KVM timekeeping 13/35] Perform hardware_enable in CPU_STARTING
callback
On 08/27/2010 06:32 AM, Jan Kiszka wrote:
> Zachary Amsden wrote:
>
>> The CPU_STARTING callback was added upstream with the intention
>> of being used for KVM, specifically for the hardware enablement
>> that must be done before we can run in hardware virt. It had
>> bugs on the x86_64 architecture at the time, where it was called
>> after CPU_ONLINE. The arches have since merged and the bug is
>> gone.
>>
> What bugs are you referring to, or since which kernel version is
> CPU_STARTING usable for KVM? I need to encode this into kvm-kmod.
>
Prior to the x86_64 / i386 merge, CPU_STARTING didn't work the same way
/ exist in the x86_64 code... most of this is historical guesswork. At
some point, the 32/64 versions of the code in smpboot.c got merged and
now it does.
Binary searching around my tree shows this timeframe:
2.6.11? - 2.6.23 : silver age ; i386 and x86_64 merge underway
|
2.6.24 : bronze age ; i386 and x86_64 deprecated
|
2.6.26 : iron age; smpboot_32.c / smpboot_64.c merge
\
2.6.28 : CPU_STARTING exists and first used
/me scratches head wondering how this affects operation on older kernels....
--
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