Use host CPUID processor info

Use host CPUID processor info

[Dong, Eddie]

Use host cpu model name, type, family, Model, stepping for guest.

Against head.

Signed-off-by: Yaozu (Eddie) Dong <eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index bacdb37..1b86a13 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -756,6 +755,10 @@ static void do_cpuid_ent(struct kvm_cpuid_entry *e,
uint32_t function)
        if ((h_edx & 0x00100000) == 0)
            e->edx &= ~0x00100000u;
     }
+    if (function == 0x80000002 || function == 0x80000003
+       || function == 0x80000004) {
+       host_cpuid(function, &e->eax, &e->ebx, &e->ecx, &e->edx);
+    }
     // sysenter isn't supported on compatibility mode on AMD.  and
syscall
     // isn't supported in compatibility mode on Intel.  so advertise
the
     // actuall cpu, and say goodbye to migration between different
vendors
@@ -768,6 +771,9 @@ static void do_cpuid_ent(struct kvm_cpuid_entry *e,
uint32_t function)
        e->ecx = bcd[1];
        e->edx = bcd[2];
     }
+    if (function == 0x1) {
+       host_cpuid(function, &e->eax, NULL, NULL, NULL);
+    }
 }

 int kvm_qemu_init_env(CPUState *cenv)

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: Use host CPUID processor info

[Avi Kivity]

Dong, Eddie wrote:
> Use host cpu model name, type, family, Model, stepping for guest.
>
> Against head.
>
>   

This is turning into a mix of the qemu cpuid and the host cpuid.  We 
need to think of a way to make this controllable.


> Signed-off-by: Yaozu (Eddie) Dong <eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
> index bacdb37..1b86a13 100644
> --- a/qemu/qemu-kvm.c
> +++ b/qemu/qemu-kvm.c
> @@ -756,6 +755,10 @@ static void do_cpuid_ent(struct kvm_cpuid_entry *e,
> uint32_t function)
>         if ((h_edx & 0x00100000) == 0)
>             e->edx &= ~0x00100000u;
>      }
> +    if (function == 0x80000002 || function == 0x80000003
> +       || function == 0x80000004) {
> +       host_cpuid(function, &e->eax, &e->ebx, &e->ecx, &e->edx);
> +    }
>      // sysenter isn't supported on compatibility mode on AMD.  and
> syscall
>      // isn't supported in compatibility mode on Intel.  so advertise
> the
>      // actuall cpu, and say goodbye to migration between different
> vendors
> @@ -768,6 +771,9 @@ static void do_cpuid_ent(struct kvm_cpuid_entry *e,
> uint32_t function)
>         e->ecx = bcd[1];
>         e->edx = bcd[2];
>      }
> +    if (function == 0x1) {
> +       host_cpuid(function, &e->eax, NULL, NULL, NULL);
> +    }
>  }
>
>  int kvm_qemu_init_env(CPUState *cenv)
>   


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


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: Use host CPUID processor info

[Dong, Eddie]

Avi Kivity wrote:
> Dong, Eddie wrote:
>> Use host cpu model name, type, family, Model, stepping for guest.
>> 
>> Against head.
>> 
>> 
> 
> This is turning into a mix of the qemu cpuid and the host cpuid.  We
> need to think of a way to make this controllable.
> 
Actually I am wondering why we need a Qemu CPUID. A basic concept of
virtualization is that good user software (following ABI) will not know
if it is running in VM or natively. But now with qemu cpuid, any
application knows "I am running in a VM". Is that really what we want?

thanks, eddie

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: Use host CPUID processor info

[Avi Kivity]

Dong, Eddie wrote:
> Avi Kivity wrote:
>   
>> Dong, Eddie wrote:
>>     
>>> Use host cpu model name, type, family, Model, stepping for guest.
>>>
>>> Against head.
>>>
>>>
>>>       
>> This is turning into a mix of the qemu cpuid and the host cpuid.  We
>> need to think of a way to make this controllable.
>>
>>     
> Actually I am wondering why we need a Qemu CPUID. A basic concept of
> virtualization is that good user software (following ABI) will not know
> if it is running in VM or natively. But now with qemu cpuid, any
> application knows "I am running in a VM". Is that really what we want?
>   

One of the uses of virtualization is to abstract the underlying 
hardware, so that a VM image can run on any platform (live migration is 
an example of this use case).  For that we must not let any detail of 
the hardware be visible.

On the other hand, other users (desktop users, or users with homogeneous 
server farms) will want to use the full capabilities of the hardware, 
requiring the host cpuid to be exposed.

We need to support both use cases.

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


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: Use host CPUID processor info

[Dong, Eddie]

Avi Kivity wrote:
> 
> One of the uses of virtualization is to abstract the underlying
> hardware, so that a VM image can run on any platform (live
> migration is
> an example of this use case).  For that we must not let any detail of
> the hardware be visible. 

I doutb about the live migration cross different architecture. A VM
using AMD 3DNow can't be migrated to Intel Box. Even within Intel
processores, A VM using SSE2 can't be migrated to a platform w/o SSE2
support.

Only if the VM is using the minimal instruction set, minimal features
may be able to live migrate to other platforms. If this is the purpose,
probably we can use an ancient processor model for the VM to achieve
best migration capability in case hybrid processor is adopted. In that
way we meet both requirement: live migration and app doesn't know it is
a VM.

Further more, there needs a capibility check for live migration to see
if it can be migrated to a new platform. If we use host processor model,
Qemu can simply check both new processor model and required one to see
if migration can be done, if we use virtual processor model, say qemu
processor, we have trouble: A vm using qemu processor compiled with SSE2
can't be migrated to a new platform w/o SSE2 though the capability check
at migration decision make time says OK (both are qemu processoe). 

I think we need to revisit the policy here.

Eddie

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: Use host CPUID processor info

[Avi Kivity]

Dong, Eddie wrote:
> Avi Kivity wrote:
>   
>> One of the uses of virtualization is to abstract the underlying
>> hardware, so that a VM image can run on any platform (live
>> migration is
>> an example of this use case).  For that we must not let any detail of
>> the hardware be visible. 
>>     
>
> I doutb about the live migration cross different architecture. A VM
> using AMD 3DNow can't be migrated to Intel Box. Even within Intel
> processores, A VM using SSE2 can't be migrated to a platform w/o SSE2
> support.
>
> Only if the VM is using the minimal instruction set, minimal features
> may be able to live migrate to other platforms. If this is the purpose,
> probably we can use an ancient processor model for the VM to achieve
> best migration capability in case hybrid processor is adopted. In that
> way we meet both requirement: live migration and app doesn't know it is
> a VM.
>   

It doesn't have to be too ancient.  All virtualization capable 
processors support at least sse2 (and maybe sse3 too).

> Further more, there needs a capibility check for live migration to see
> if it can be migrated to a new platform. If we use host processor model,
> Qemu can simply check both new processor model and required one to see
> if migration can be done, if we use virtual processor model, say qemu
> processor, we have trouble: A vm using qemu processor compiled with SSE2
> can't be migrated to a new platform w/o SSE2 though the capability check
> at migration decision make time says OK (both are qemu processoe). 

No, you only need to check that the host processor is a superset of the 
virtualized processor.

A management solution can also compute a cpuid that is common to all 
machines in the farm and tell qemu to use that via the command line.


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


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/