[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/3] push CPUID level to 4 to allow Intel multic

From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 2/3] push CPUID level to 4 to allow Intel multicore decoding
Date: Thu, 20 Aug 2009 14:06:06 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3

On 08/20/2009 01:36 PM, Andre Przywara wrote:
Avi Kivity wrote:
On 08/19/2009 04:42 PM, Andre Przywara wrote:
Intel CPUs store the number of cores in CPUID leaf 4. So push
the maxleaf value to 4 to allow the guests access to this leaf.

There's a slight compatibility risk here. If a guest has broken handling for cpuid level 4, then upgrading qemu would cause it to behave differently.

I don't think that's an issue for this patch, just highlighting the need for a systematic treatment of backward compatibility.

If you have real headaches about it, I have two options:

It's really an imaginary headache.

What about allowing level to be specified at -cpu command line? This would allow users to say -cpu qemu64,level=2 if they experience problems. The default would stay at level 4.

I think this is the best option.

The other option would be to push the level only to four if we use more than one thread or core.

In my research it turned out that Intel pushed the level beyond 4 with Pentium4 Prescott (probably with the introduction of real dual core chips to differentiate threads and cores), so this is quite some time ago. So I doubt that there are serious issues out there.

I only pointed this out as an example of a new feature that has an effect even if it is not used, something we should beware of.

The only problem I can think of is that the advertised cache topology is somehow bogus and could confuse OSes.

So long as it's smaller than contemporary caches we should be fine.

btw, does -cpu host use the host cpu cache information?

error compiling committee.c: too many arguments to function

reply via email to

[Prev in Thread] Current Thread [Next in Thread]