From: "H. Peter Anvin" <hpa@zytor.com>
To: Andi Kleen <ak@suse.de>
Cc: akpm@osdl.org, davej@codemonkey.org.uk,
cpufreq@lists.linux.org.uk, linux-kernel@vger.kernel.org,
Alexey Dobriyan <adobriyan@sw.ru>,
devel@openvz.org
Subject: Re: [PATCH 1/3] Introduce cpuid_on_cpu() and cpuid_eax_on_cpu()
Date: Mon, 02 Apr 2007 09:20:16 -0700 [thread overview]
Message-ID: <46112D40.20508@zytor.com> (raw)
In-Reply-To: <200704021410.29623.ak@suse.de>
Andi Kleen wrote:
> On Monday 02 April 2007 13:38, Alexey Dobriyan wrote:
>> They will be used by cpuid driver and powernow-k8 cpufreq driver.
>>
>> With these changes powernow-k8 driver could run correctly on OpenVZ kernels
>> with virtual cpus enabled (SCHED_VCPU).
>
> This means openvz has multiple virtual CPU levels? One for cpuid/rdmsr and one
> for the rest of the kernel? Both powernow-k8 and cpuid attempt to schedule
> to the target CPU so they should already run there. But it is some other CPU,
> but when they ask your _on_cpu() functions they suddenly get a "real" CPU?
> Where is the difference between these levels of virtualness?
>
The CPUID and MSR drivers do not schedule to the target CPU; instead, on
hardware, they rely on IPI'ing the target processor if it is not the one
that's currently running.
There were a lot of discussion back when about which was the better
solution. Alan Cox, in particular, really preferred the interrupt
solution as being less likely to cause implicit deadlock.
I do want to add that it's been on my list for some time -- in fact, I
keep implementing it half-way and then having other things to do -- to
add MSR and CPUID ioctls() that allow the full register file to be set
and read back, in order to support architecturally broken MSR and CPUID
levels.
-hpa
WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com>
To: Andi Kleen <ak@suse.de>
Cc: Alexey Dobriyan <adobriyan@sw.ru>,
akpm@osdl.org, linux-kernel@vger.kernel.org, devel@openvz.org,
cpufreq@lists.linux.org.uk, davej@codemonkey.org.uk
Subject: Re: [PATCH 1/3] Introduce cpuid_on_cpu() and cpuid_eax_on_cpu()
Date: Mon, 02 Apr 2007 09:20:16 -0700 [thread overview]
Message-ID: <46112D40.20508@zytor.com> (raw)
In-Reply-To: <200704021410.29623.ak@suse.de>
Andi Kleen wrote:
> On Monday 02 April 2007 13:38, Alexey Dobriyan wrote:
>> They will be used by cpuid driver and powernow-k8 cpufreq driver.
>>
>> With these changes powernow-k8 driver could run correctly on OpenVZ kernels
>> with virtual cpus enabled (SCHED_VCPU).
>
> This means openvz has multiple virtual CPU levels? One for cpuid/rdmsr and one
> for the rest of the kernel? Both powernow-k8 and cpuid attempt to schedule
> to the target CPU so they should already run there. But it is some other CPU,
> but when they ask your _on_cpu() functions they suddenly get a "real" CPU?
> Where is the difference between these levels of virtualness?
>
The CPUID and MSR drivers do not schedule to the target CPU; instead, on
hardware, they rely on IPI'ing the target processor if it is not the one
that's currently running.
There were a lot of discussion back when about which was the better
solution. Alan Cox, in particular, really preferred the interrupt
solution as being less likely to cause implicit deadlock.
I do want to add that it's been on my list for some time -- in fact, I
keep implementing it half-way and then having other things to do -- to
add MSR and CPUID ioctls() that allow the full register file to be set
and read back, in order to support architecturally broken MSR and CPUID
levels.
-hpa
next prev parent reply other threads:[~2007-04-02 16:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-02 11:38 [PATCH 1/3] Introduce cpuid_on_cpu() and cpuid_eax_on_cpu() Alexey Dobriyan
2007-04-02 12:10 ` Andi Kleen
2007-04-02 16:20 ` H. Peter Anvin [this message]
2007-04-02 16:20 ` H. Peter Anvin
2007-04-02 16:55 ` Andi Kleen
2007-04-02 16:55 ` Andi Kleen
2007-04-03 13:39 ` Alexey Dobriyan
2007-04-03 13:42 ` Andi Kleen
2007-04-03 14:55 ` Alexey Dobriyan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46112D40.20508@zytor.com \
--to=hpa@zytor.com \
--cc=adobriyan@sw.ru \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=cpufreq@lists.linux.org.uk \
--cc=davej@codemonkey.org.uk \
--cc=devel@openvz.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.