We've been supporting kvmclock MSRs in the 0x4b564d00-0x4b564dff range
for a while now, but we're not exposing it yet, meaning nobody is using it.
This simple patch takes care of that.
Signed-off-by: Glauber Costa <[email protected]>
---
arch/x86/kvm/x86.c | 1 +
include/linux/kvm.h | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 8575d85..c0808db 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1966,6 +1966,7 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_SET_TSS_ADDR:
case KVM_CAP_EXT_CPUID:
case KVM_CAP_CLOCKSOURCE:
+ case KVM_CAP_CLOCKSOURCE2:
case KVM_CAP_PIT:
case KVM_CAP_NOP_IO_DELAY:
case KVM_CAP_MP_STATE:
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index ea2dc1a..a15d2e8 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -541,6 +541,7 @@ struct kvm_ppc_pvinfo {
#define KVM_CAP_PPC_GET_PVINFO 57
#define KVM_CAP_PPC_IRQ_LEVEL 58
#define KVM_CAP_ASYNC_PF 59
+#define KVM_CAP_CLOCKSOURCE2 60 /* hypervisor supports MSRs at upper range */
#ifdef KVM_CAP_IRQ_ROUTING
--
1.7.3.4
On Wed, Feb 23, 2011 at 12:44:14PM -0500, Glauber Costa wrote:
> We've been supporting kvmclock MSRs in the 0x4b564d00-0x4b564dff range
> for a while now, but we're not exposing it yet, meaning nobody is using it.
> This simple patch takes care of that.
Is nobody using it because it was never exposed? Or because nobody ever
needed it, and we don't care (thus don't bother supporting it).
-- Steve
On Thu, 2011-02-24 at 18:24 -0500, Steven Rostedt wrote:
> On Wed, Feb 23, 2011 at 12:44:14PM -0500, Glauber Costa wrote:
> > We've been supporting kvmclock MSRs in the 0x4b564d00-0x4b564dff range
> > for a while now, but we're not exposing it yet, meaning nobody is using it.
> > This simple patch takes care of that.
>
> Is nobody using it because it was never exposed? Or because nobody ever
> needed it, and we don't care (thus don't bother supporting it).
>
The former. Our guest kernels will only rely on features that are
exposed, meaning that if they are not, the guest kernel will never know
it is available.
On Thu, 2011-02-24 at 20:48 -0300, Glauber Costa wrote:
> On Thu, 2011-02-24 at 18:24 -0500, Steven Rostedt wrote:
> > On Wed, Feb 23, 2011 at 12:44:14PM -0500, Glauber Costa wrote:
> > > We've been supporting kvmclock MSRs in the 0x4b564d00-0x4b564dff range
> > > for a while now, but we're not exposing it yet, meaning nobody is using it.
> > > This simple patch takes care of that.
> >
> > Is nobody using it because it was never exposed? Or because nobody ever
> > needed it, and we don't care (thus don't bother supporting it).
> >
> The former. Our guest kernels will only rely on features that are
> exposed, meaning that if they are not, the guest kernel will never know
> it is available.
>
Might want to rephrase your change log, as to me it sounds like nobody
is using it because it is not needed. Adding the "Our guest..." from
your response to the change log will clear that up.
Thanks,
-- Steve
On Thu, 2011-02-24 at 18:54 -0500, Steven Rostedt wrote:
> On Thu, 2011-02-24 at 20:48 -0300, Glauber Costa wrote:
> > On Thu, 2011-02-24 at 18:24 -0500, Steven Rostedt wrote:
> > > On Wed, Feb 23, 2011 at 12:44:14PM -0500, Glauber Costa wrote:
> > > > We've been supporting kvmclock MSRs in the 0x4b564d00-0x4b564dff range
> > > > for a while now, but we're not exposing it yet, meaning nobody is using it.
> > > > This simple patch takes care of that.
> > >
> > > Is nobody using it because it was never exposed? Or because nobody ever
> > > needed it, and we don't care (thus don't bother supporting it).
> > >
> > The former. Our guest kernels will only rely on features that are
> > exposed, meaning that if they are not, the guest kernel will never know
> > it is available.
> >
>
> Might want to rephrase your change log, as to me it sounds like nobody
> is using it because it is not needed. Adding the "Our guest..." from
> your response to the change log will clear that up.
>
> Thanks,
I can do that, sure.
OTOH, I know avi changed changelogs for clarity a couple of times
before, so if there is no code change needed, maybe he think it is
easier to rephrase it before picking it up.
Avi?
On 02/25/2011 03:11 PM, Glauber Costa wrote:
> On Thu, 2011-02-24 at 18:54 -0500, Steven Rostedt wrote:
> > On Thu, 2011-02-24 at 20:48 -0300, Glauber Costa wrote:
> > > On Thu, 2011-02-24 at 18:24 -0500, Steven Rostedt wrote:
> > > > On Wed, Feb 23, 2011 at 12:44:14PM -0500, Glauber Costa wrote:
> > > > > We've been supporting kvmclock MSRs in the 0x4b564d00-0x4b564dff range
> > > > > for a while now, but we're not exposing it yet, meaning nobody is using it.
> > > > > This simple patch takes care of that.
> > > >
> > > > Is nobody using it because it was never exposed? Or because nobody ever
> > > > needed it, and we don't care (thus don't bother supporting it).
> > > >
> > > The former. Our guest kernels will only rely on features that are
> > > exposed, meaning that if they are not, the guest kernel will never know
> > > it is available.
> > >
> >
> > Might want to rephrase your change log, as to me it sounds like nobody
> > is using it because it is not needed. Adding the "Our guest..." from
> > your response to the change log will clear that up.
> >
> > Thanks,
> I can do that, sure.
>
> OTOH, I know avi changed changelogs for clarity a couple of times
> before, so if there is no code change needed, maybe he think it is
> easier to rephrase it before picking it up.
>
> Avi?
>
If that's the only change, no problem.
--
error compiling committee.c: too many arguments to function
On 02/23/2011 07:44 PM, Glauber Costa wrote:
> We've been supporting kvmclock MSRs in the 0x4b564d00-0x4b564dff range
> for a while now, but we're not exposing it yet, meaning nobody is using it.
> This simple patch takes care of that.
We're exposing them via KVM_GET_SUPPORTED_CPUID, leaf KVM_CPUID_FEATURES.
--
error compiling committee.c: too many arguments to function
On Sun, 2011-02-27 at 14:16 +0200, Avi Kivity wrote:
> On 02/23/2011 07:44 PM, Glauber Costa wrote:
> > We've been supporting kvmclock MSRs in the 0x4b564d00-0x4b564dff range
> > for a while now, but we're not exposing it yet, meaning nobody is using it.
> > This simple patch takes care of that.
>
> We're exposing them via KVM_GET_SUPPORTED_CPUID, leaf KVM_CPUID_FEATURES.
>
Our userspace does not really use it, and rely on the capability list.
Historically, we've been relying on the capabilities mechanism to
indicate what exists and what does not.
On 02/28/2011 03:24 PM, Glauber Costa wrote:
> On Sun, 2011-02-27 at 14:16 +0200, Avi Kivity wrote:
> > On 02/23/2011 07:44 PM, Glauber Costa wrote:
> > > We've been supporting kvmclock MSRs in the 0x4b564d00-0x4b564dff range
> > > for a while now, but we're not exposing it yet, meaning nobody is using it.
> > > This simple patch takes care of that.
> >
> > We're exposing them via KVM_GET_SUPPORTED_CPUID, leaf KVM_CPUID_FEATURES.
> >
> Our userspace does not really use it, and rely on the capability list.
> Historically, we've been relying on the capabilities mechanism to
> indicate what exists and what does not.
Yes. I believe this bit marked the change point.
Anyway, it's exposed, and it's a lot better for userspace to make use of
KVM_GET_SUPPORTED_CPUID since it will work on more kernels.
--
error compiling committee.c: too many arguments to function
On 02/28/2011 03:30 PM, Avi Kivity wrote:
> On 02/28/2011 03:24 PM, Glauber Costa wrote:
>> On Sun, 2011-02-27 at 14:16 +0200, Avi Kivity wrote:
>> > On 02/23/2011 07:44 PM, Glauber Costa wrote:
>> > > We've been supporting kvmclock MSRs in the 0x4b564d00-0x4b564dff
>> range
>> > > for a while now, but we're not exposing it yet, meaning nobody
>> is using it.
>> > > This simple patch takes care of that.
>> >
>> > We're exposing them via KVM_GET_SUPPORTED_CPUID, leaf
>> KVM_CPUID_FEATURES.
>> >
>> Our userspace does not really use it, and rely on the capability list.
>> Historically, we've been relying on the capabilities mechanism to
>> indicate what exists and what does not.
>
> Yes. I believe this bit marked the change point.
>
> Anyway, it's exposed, and it's a lot better for userspace to make use
> of KVM_GET_SUPPORTED_CPUID since it will work on more kernels.
>
btw, it should work with -cpu host as well, no?
--
error compiling committee.c: too many arguments to function