Accessing pv_info from userland

Accessing pv_info from userland

[Bryan McLellan]

Is there any way to access pv_info from userland? It would be useful
for determining what type of virtualization the machine was running
on.

Bryan McLellan

Re: Accessing pv_info from userland

[Glauber Costa]

On Sat, Jan 31, 2009 at 10:19 AM, Bryan McLellan <btm@loftninjas.org> wrote:
> Is there any way to access pv_info from userland? It would be useful
> for determining what type of virtualization the machine was running
> on.

there are usually cpuid functions reserved for that.

for kvm, you can run function 0x40000000, and if you get
ebx =  0x4b4d564b
ecx =  0x564b4d56
edx =  0x4d

you're running KVM.


-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: Accessing pv_info from userland

[Anthony Liguori]

Glauber Costa wrote:
> On Sat, Jan 31, 2009 at 10:19 AM, Bryan McLellan <btm@loftninjas.org> wrote:
>   
>> Is there any way to access pv_info from userland? It would be useful
>> for determining what type of virtualization the machine was running
>> on.
>>     
>
> there are usually cpuid functions reserved for that.
>
> for kvm, you can run function 0x40000000, and if you get
> ebx =  0x4b4d564b
> ecx =  0x564b4d56
> edx =  0x4d
>
> you're running KVM.
>   

Since this is a pretty standard mechanism, it may make sense to include 
this signature in /proc/cpuinfo if someone is up to writing a patch.  It 
could also be useful to expose the PV features mask in cpuinfo too.

Regards,

Anthony Liguori

Re: Accessing pv_info from userland

[Glauber Costa]

On Sat, Jan 31, 2009 at 5:36 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Glauber Costa wrote:
>>
>> On Sat, Jan 31, 2009 at 10:19 AM, Bryan McLellan <btm@loftninjas.org>
>> wrote:
>>
>>>
>>> Is there any way to access pv_info from userland? It would be useful
>>> for determining what type of virtualization the machine was running
>>> on.
>>>
>>
>> there are usually cpuid functions reserved for that.
>>
>> for kvm, you can run function 0x40000000, and if you get
>> ebx =  0x4b4d564b
>> ecx =  0x564b4d56
>> edx =  0x4d
>>
>> you're running KVM.
>>
>
> Since this is a pretty standard mechanism, it may make sense to include this
> signature in /proc/cpuinfo if someone is up to writing a patch.  It could
> also be useful to expose the PV features mask in cpuinfo too.
>

What for? We already expose a QEMU cpu type that shows up in cpuinfo as so.
All we'd have to do would be put the kvm information in the cpu type
too. This would work
in all kernels, without the need to patch.
-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: Accessing pv_info from userland

[Bryan McLellan]

On Sat, Jan 31, 2009 at 11:55 AM, Glauber Costa <glommer@gmail.com> wrote:
>> Since this is a pretty standard mechanism, it may make sense to include this
>> signature in /proc/cpuinfo if someone is up to writing a patch.  It could
>> also be useful to expose the PV features mask in cpuinfo too.
>>
>
> What for? We already expose a QEMU cpu type that shows up in cpuinfo as so.
> All we'd have to do would be put the kvm information in the cpu type
> too. This would work
> in all kernels, without the need to patch.

I'm not sure what you mean by "run cpuid function". On my intrepid kvm
guest running 2.6.27 the cpuid utility has no options to specify a
fucntion, nor do the numbers you provided match any in the e[abcd]x
columns it returns. A google search for "run cpuid function" returns
no results.

It would be nice to have KVM information somewhere to more easily
differentiate between qemu. However briefly perusing the pv_info
struct in the kernel source shows useful information like the
virtualization type (beyond kvm, including xen and others) and
paravirtualization information.

There should be some method to tell we're on kvm without utilities
that aren't in most distros base install and ideally it should be
simble. Xen exposes /proc/xen from which one can determine these
things. I'm not arguing for that, but I'm saying it works.

Bryan McLellan

Re: Accessing pv_info from userland

[Glauber Costa]

On Sat, Jan 31, 2009 at 6:20 PM, Bryan McLellan <btm@loftninjas.org> wrote:
> On Sat, Jan 31, 2009 at 11:55 AM, Glauber Costa <glommer@gmail.com> wrote:
>>> Since this is a pretty standard mechanism, it may make sense to include this
>>> signature in /proc/cpuinfo if someone is up to writing a patch.  It could
>>> also be useful to expose the PV features mask in cpuinfo too.
>>>
>>
>> What for? We already expose a QEMU cpu type that shows up in cpuinfo as so.
>> All we'd have to do would be put the kvm information in the cpu type
>> too. This would work
>> in all kernels, without the need to patch.
>
> I'm not sure what you mean by "run cpuid function". On my intrepid kvm
> guest running 2.6.27 the cpuid utility has no options to specify a
> fucntion, nor do the numbers you provided match any in the e[abcd]x
> columns it returns. A google search for "run cpuid function" returns
> no results.
It's not an utility. It's an asm instruction (that could be easily
converted into
an utility). This is the very instruction that the kernel uses to grab
information
that end up in /proc/cpuinfo

>
> It would be nice to have KVM information somewhere to more easily
> differentiate between qemu. However briefly perusing the pv_info
> struct in the kernel source shows useful information like the
> virtualization type (beyond kvm, including xen and others) and
> paravirtualization information.
>
> There should be some method to tell we're on kvm without utilities
> that aren't in most distros base install and ideally it should be
> simble. Xen exposes /proc/xen from which one can determine these
> things. I'm not arguing for that, but I'm saying it works.
>

I don't disagree. But I believe exposing it in the cpu model makes it
easier, since we won't then depend on any kind of kernel patch.
It'll work no matter how old your guest is.

-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: Accessing pv_info from userland

[Anthony Liguori]

Glauber Costa wrote:
> On Sat, Jan 31, 2009 at 5:36 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
>   
>> Since this is a pretty standard mechanism, it may make sense to include this
>> signature in /proc/cpuinfo if someone is up to writing a patch.  It could
>> also be useful to expose the PV features mask in cpuinfo too.
>>
>>     
>
> What for? We already expose a QEMU cpu type that shows up in cpuinfo as so.
> All we'd have to do would be put the kvm information in the cpu type
> too. This would work
> in all kernels, without the need to patch.
>   
What I'm talking about, is something like:

HypervisorPresent:   yes
HypervisorType:   KVM

Where HypervisorVendor could be KVM, Hyper-V, or ESX based on what the 
cpuid leaf matched.

Regards,

Anthony Liguori

Re: Accessing pv_info from userland

[Alexander Graf]

On 31.01.2009, at 22:08, Anthony Liguori <anthony@codemonkey.ws> wrote:

> Glauber Costa wrote:
>> On Sat, Jan 31, 2009 at 5:36 PM, Anthony Liguori <anthony@codemonkey.ws 
>> > wrote:
>>
>>> Since this is a pretty standard mechanism, it may make sense to  
>>> include this
>>> signature in /proc/cpuinfo if someone is up to writing a patch.   
>>> It could
>>> also be useful to expose the PV features mask in cpuinfo too.
>>>
>>>
>>
>> What for? We already expose a QEMU cpu type that shows up in  
>> cpuinfo as so.
>> All we'd have to do would be put the kvm information in the cpu type
>> too. This would work
>> in all kernels, without the need to patch.
>>
> What I'm talking about, is something like:
>
> HypervisorPresent:   yes
> HypervisorType:   KVM

Why not rather do

Platform: native

Or

Platform: KVM

So things stay consistent :)

Alex

>
>
> Where HypervisorVendor could be KVM, Hyper-V, or ESX based on what  
> the cpuid leaf matched.
>
> Regards,
>
> Anthony Liguori
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Accessing pv_info from userland

[Anthony Liguori]

Alexander Graf wrote:
> On 31.01.2009, at 22:08, Anthony Liguori <anthony@codemonkey.ws> wrote:
>
> Why not rather do
>
> Platform: native

Some architectures may find the use of "native" to describe the absence 
of a hypervisor as being somewhat offensive.  I can think of two 
particular architectures where the "native" configuration includes a 
hypervisor :-)

Regards,

Anthony Liguori

Re: Accessing pv_info from userland

[Alexander Graf]

On 01.02.2009, at 01:55, Anthony Liguori <anthony@codemonkey.ws> wrote:

> Alexander Graf wrote:
>> On 31.01.2009, at 22:08, Anthony Liguori <anthony@codemonkey.ws>  
>> wrote:
>>
>> Why not rather do
>>
>> Platform: native
>
> Some architectures may find the use of "native" to describe the  
> absence of a hypervisor as being somewhat offensive.  I can think of  
> two particular architectures where the "native" configuration  
> includes a hypervisor :-)

Then expose them as such ;). It's not like you couldn't do

Platform: z/vm

Right?

So this does make sense for everyone, no?

Alex

>
>
> Regards,
>
> Anthony Liguori
>

Re: Accessing pv_info from userland

[Avi Kivity]

Glauber Costa wrote:
> What for? We already expose a QEMU cpu type that shows up in cpuinfo as so.
> All we'd have to do would be put the kvm information in the cpu type
> too. This would work
> in all kernels, without the need to patch.
>   

For client virtualization (no migration) we'll want to support a mode 
where we let the guest see the host cpuid (or as much of it as we can).

-- 
error compiling committee.c: too many arguments to function

Re: Accessing pv_info from userland

[Glauber Costa]

On Tue, Feb 3, 2009 at 8:50 AM, Avi Kivity <avi@redhat.com> wrote:
> Glauber Costa wrote:
>>
>> What for? We already expose a QEMU cpu type that shows up in cpuinfo as
>> so.
>> All we'd have to do would be put the kvm information in the cpu type
>> too. This would work
>> in all kernels, without the need to patch.
>>
>
> For client virtualization (no migration) we'll want to support a mode where
> we let the guest see the host cpuid (or as much of it as we can).

And how exactly does that invalidate what I've said ?

As we can select the cpu type, we can easily pick one that expose as
much of the underlying cpu
as possible.

-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: Accessing pv_info from userland

[Avi Kivity]

Glauber Costa wrote:
> On Tue, Feb 3, 2009 at 8:50 AM, Avi Kivity <avi@redhat.com> wrote:
>   
>> Glauber Costa wrote:
>>     
>>> What for? We already expose a QEMU cpu type that shows up in cpuinfo as
>>> so.
>>> All we'd have to do would be put the kvm information in the cpu type
>>> too. This would work
>>> in all kernels, without the need to patch.
>>>
>>>       
>> For client virtualization (no migration) we'll want to support a mode where
>> we let the guest see the host cpuid (or as much of it as we can).
>>     
>
> And how exactly does that invalidate what I've said ?
>   

You'll want to expose AuthenticIntel or GenuineAMD (with the full cpu 
brand string) in this model.  So no TheOneTrueQEMU cpu type.

> As we can select the cpu type, we can easily pick one that expose as
> much of the underlying cpu
> as possible.
>   

This includes the cpu type...

Hypervisor presence and type is in addition to the cpu type, not a 
replacement.

-- 
error compiling committee.c: too many arguments to function