CPUID emulation

CPUID emulation

[Stephane Eranian]

Hello,

Looking at kvm-26, it seems that the CPUID values as seen by the guest OS
are still hardcoded for i386/x86-64 at least.

For performance counter virtualization, the guest needs to see the *actual*
family/model information in order to correctly program the counters.

It would be fairly simple to grab that information from /proc/cpuinfo
at init time in qemu.

However, I am wondering if there would be side effects of using the
actual CPUID which could cause troubles to KVM or the guest.

Any comments on this?

Thanks.

-- 
-Stephane

-------------------------------------------------------------------------
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: CPUID emulation

[Avi Kivity]

Stephane Eranian wrote:
> Hello,
>
> Looking at kvm-26, it seems that the CPUID values as seen by the guest OS
> are still hardcoded for i386/x86-64 at least.
>
> For performance counter virtualization, the guest needs to see the *actual*
> family/model information in order to correctly program the counters.
>
> It would be fairly simple to grab that information from /proc/cpuinfo
> at init time in qemu.
>
> However, I am wondering if there would be side effects of using the
> actual CPUID which could cause troubles to KVM or the guest.
>
>   

The main issue is migration (and save/restore).  If you migrate to a 
host with fewer capabilities, applications may fail when they use 
unavailable instructions that they successfully detected earlier.

I think the best solution is to default to the host's capabilities, but 
allow command line switches to override them.  This way a management 
application in a server farm can set a site-wide least common 
denominator, while a home user can enjoy the latest and greatest 
instructions on their machine.

Upstream qemu already has a -cpu (or similar) switch for non-x86; we can 
probably use that.

(there's another possible issue - some future features may require 
support from the hypervisor - that may conflict with defaulting to to 
the host feature set.  maybe kvm should mask out any unknown features)

-- 
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: CPUID emulation

[Stephane Eranian]

Avi,

On Thu, May 31, 2007 at 11:39:04AM +0300, Avi Kivity wrote:
> Stephane Eranian wrote:
> >Hello,
> >
> >Looking at kvm-26, it seems that the CPUID values as seen by the guest OS
> >are still hardcoded for i386/x86-64 at least.
> >
> >For performance counter virtualization, the guest needs to see the *actual*
> >family/model information in order to correctly program the counters.
> >
> >It would be fairly simple to grab that information from /proc/cpuinfo
> >at init time in qemu.
> >
> >However, I am wondering if there would be side effects of using the
> >actual CPUID which could cause troubles to KVM or the guest.
> >
> >  
> 
> The main issue is migration (and save/restore).  If you migrate to a 
> host with fewer capabilities, applications may fail when they use 
> unavailable instructions that they successfully detected earlier.
> 
In the case of heterogeneous migration, clearly performance counters
will not work well, especially for unmodified guests. But I  can also
see problems when migrating from Intel Core to older P4 for instance.

> I think the best solution is to default to the host's capabilities, but 
> allow command line switches to override them.  This way a management 
> application in a server farm can set a site-wide least common 
> denominator, while a home user can enjoy the latest and greatest 
> instructions on their machine.
> 
I agree.

> Upstream qemu already has a -cpu (or similar) switch for non-x86; we can 
> probably use that.
> 

Probably, but in my particular case, you'd have to be able to specify
vendor/family/model.

> (there's another possible issue - some future features may require 
> support from the hypervisor - that may conflict with defaulting to to 
> the host feature set.  maybe kvm should mask out any unknown features)
> 

The question is how do you identify unknown features which do require
KVM support?

-- 
-Stephane

-------------------------------------------------------------------------
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: CPUID emulation

[Avi Kivity]

Stephane Eranian wrote:
>>
>> The main issue is migration (and save/restore).  If you migrate to a 
>> host with fewer capabilities, applications may fail when they use 
>> unavailable instructions that they successfully detected earlier.
>>
>>     
> In the case of heterogeneous migration, clearly performance counters
> will not work well, especially for unmodified guests. 

Right.

> But I  can also
> see problems when migrating from Intel Core to older P4 for instance.
>
>   

If the guest cpuid is set to a least common denominator, it should work.


>> Upstream qemu already has a -cpu (or similar) switch for non-x86; we can 
>> probably use that.
>>
>>     
>
> Probably, but in my particular case, you'd have to be able to specify
> vendor/family/model.
>
>   

Right.  It will have to be quite elaborate.

>> (there's another possible issue - some future features may require 
>> support from the hypervisor - that may conflict with defaulting to to 
>> the host feature set.  maybe kvm should mask out any unknown features)
>>
>>     
>
> The question is how do you identify unknown features which do require
> KVM support?
>
>   

Yes.  Obviously we don't know anything about future features, so we can 
just mask out any feature that is unknown today, and update the mask 
when new features are available (whether they require kernel support or 
not).

This masking can be performed in user space, so upgrading is not too 
hard (or even allow a command-line override).

-- 
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: CPUID emulation

[Stephane Eranian]

Avi,

On Thu, May 31, 2007 at 02:35:44PM +0300, Avi Kivity wrote:
> >>
> >>    
> >In the case of heterogeneous migration, clearly performance counters
> >will not work well, especially for unmodified guests. 
> 
> Right.
> 
> >But I  can also
> >see problems when migrating from Intel Core to older P4 for instance.
> >
> >  
> 
> If the guest cpuid is set to a least common denominator, it should work.
> 
There is no common denominator between a P4 and Intel Core 2 Duo for the
performance counters. So you cannot simply use a generic member of family
15 to fake the guest cpuid runnning on Intel Core 2 Duo host.

-- 

-Stephane

-------------------------------------------------------------------------
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: CPUID emulation

[Avi Kivity]

Stephane Eranian wrote:
>>
>> If the guest cpuid is set to a least common denominator, it should work.
>>
>>     
> There is no common denominator between a P4 and Intel Core 2 Duo for the
> performance counters. So you cannot simply use a generic member of family
> 15 to fake the guest cpuid runnning on Intel Core 2 Duo host.
>
>   

So, the performance counter functionality will not be available if you 
have a mixed server farm with these processors.

If applications use model version to detect performance counters, and 
not cpuid bits, then there is no way to prevent guests using performance 
counters.  Fortunately this is limited to specialized applications.

-- 
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: CPUID emulation

[Stephane Eranian]

Avi,

On Thu, May 31, 2007 at 02:52:05PM +0300, Avi Kivity wrote:
> Stephane Eranian wrote:
> >>
> >>If the guest cpuid is set to a least common denominator, it should work.
> >>
> >>    
> >There is no common denominator between a P4 and Intel Core 2 Duo for the
> >performance counters. So you cannot simply use a generic member of family
> >15 to fake the guest cpuid runnning on Intel Core 2 Duo host.
> >
> >  
> 
> So, the performance counter functionality will not be available if you 
> have a mixed server farm with these processors.
> 
That's like what is going to happen.

> If applications use model version to detect performance counters, and 
> not cpuid bits, then there is no way to prevent guests using performance 
> counters.  Fortunately this is limited to specialized applications.
> 
They use cpuid. I expect more and more applications/OS will rely on
performance counters to boost performance at runtime.

-- 
-Stephane

-------------------------------------------------------------------------
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: CPUID emulation

[Troy Benjegerdes]

On Thu, May 31, 2007 at 04:58:41AM -0700, Stephane Eranian wrote:
> Avi,
> 
> On Thu, May 31, 2007 at 02:52:05PM +0300, Avi Kivity wrote:
> > Stephane Eranian wrote:
> > >>
> > >>If the guest cpuid is set to a least common denominator, it should work.
> > >>
> > >>    
> > >There is no common denominator between a P4 and Intel Core 2 Duo for the
> > >performance counters. So you cannot simply use a generic member of family
> > >15 to fake the guest cpuid runnning on Intel Core 2 Duo host.
> > >
> > >  
> > 
> > So, the performance counter functionality will not be available if you 
> > have a mixed server farm with these processors.
> > 
> That's like what is going to happen.
> 
> > If applications use model version to detect performance counters, and 
> > not cpuid bits, then there is no way to prevent guests using performance 
> > counters.  Fortunately this is limited to specialized applications.
> > 
> They use cpuid. I expect more and more applications/OS will rely on
> performance counters to boost performance at runtime.

This sounds like a huge headache waiting to happen, and something that
could end up giving virtualization and KVM a bad name in the long run,
due to the inevitable bugs and performance problems that will happen
with end-users that don't know the details about what performance
counters are supported on what cpu model.

The only halfway sane solution I can think of involves having guest
support for CPU hotplug, so that a host can notify a guest that the
underlying CPU has changed.

-------------------------------------------------------------------------
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: CPUID emulation

[ron minnich]

On 5/31/07, Troy Benjegerdes <hozer-TBByXz/9jYzYtjvyW6yDsg@public.gmane.org> wrote:

> The only halfway sane solution I can think of involves having guest
> support for CPU hotplug, so that a host can notify a guest that the
> underlying CPU has changed.

well, but ... if the migration has happened, and some app is reading
the counters, and is woken up, what do you do to the app?

we had all this type of issue on bproc migration. The only conclusion
we ever reached is 'migrate only to same cpu type'. It's incredibly
messy to cover all the corner cases, and probably impossible to hit
them all.

I don't think our apps are ready to go to sleep and wake up in Kansas.

ron

-------------------------------------------------------------------------
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: CPUID emulation

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephane Eranian wrote:
> They use cpuid. I expect more and more applications/OS will rely on
> performance counters to boost performance at runtime.

That's a definitive fact.  ld.so for the longest time selects special
DSOs to load automatically based on the data.  String functions are
optimized to take cache sizes into account.  That info comes from cpuid
as well (at least on Intel CPUs).  It's crucial to get info based on the
current CPU.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFGXxRf2ijCOnn/RHQRAq+aAKC/NZ5JSSEGcdt+vqnhZC40V7iJ8gCgjqjR
+9Zh/jNBfg2DVb/2zh6fgUI=
=8HZ1
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
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/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: CPUID emulation

[H. Peter Anvin]

Ulrich Drepper wrote:
> Stephane Eranian wrote:
>> They use cpuid. I expect more and more applications/OS will rely on
>> performance counters to boost performance at runtime.
> 
> That's a definitive fact.  ld.so for the longest time selects special
> DSOs to load automatically based on the data.  String functions are
> optimized to take cache sizes into account.  That info comes from cpuid
> as well (at least on Intel CPUs).  It's crucial to get info based on the
> current CPU.

If you want migration, it's crucial that you get information that is
appropriate for the baseline you want to emulate.  Optimizations is one
thing, but if you start using SSE-12 instructions when the underlying
CPU only supports SSE-8, you're horked.

	-hpa

-------------------------------------------------------------------------
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/