Patchwork [2/3] push CPUID level to 4 to allow Intel multicore decoding

login
register
mail settings
Submitter Andre Przywara
Date Aug. 19, 2009, 1:42 p.m.
Message ID <1250689362-11067-3-git-send-email-andre.przywara@amd.com>
Download mbox | patch
Permalink /patch/31644/
State Superseded
Headers show

Comments

Andre Przywara - Aug. 19, 2009, 1:42 p.m.
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.

Signed-off-by: Andre Przywara <andre.przywara@amd.com>
---
 target-i386/helper.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
Avi Kivity - Aug. 20, 2009, 10:06 a.m.
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.
Andre Przywara - Aug. 20, 2009, 10:36 a.m.
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:

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.

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. The only 
problem I can think of is that the advertised cache topology is somehow 
bogus and could confuse OSes.

Regards,
Andre.
Avi Kivity - Aug. 20, 2009, 11:06 a.m.
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?
Jamie Lokier - Aug. 20, 2009, 7:30 p.m.
Andre Przywara wrote:
> 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.

Pentium 4 wasn't that long ago, from a point of view of running legacy
guests.

I see quite a lot of code in Linux (to pick an example - presumably
also other OSes) which checks for things by looking at model and
family number, so I wonder if it's wise to depart a long way from
CPUIDs which resemble real hardware which has existed.

We've already seen a problem along these lines, which was the x86
CPUID_SEP feature not getting used properly, but that was quite well
hidden, only affecting one application (Skype) on Windows.

Could it make more sense to, in effect, upgrade the default CPUID
to Pentium 4 (instead of Pentium Pro) when cores > 1?

-- Jamie
Andre Przywara - Aug. 20, 2009, 9:35 p.m.
Jamie Lokier wrote:
> Andre Przywara wrote:
>> 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.
> 
> Pentium 4 wasn't that long ago, from a point of view of running legacy
> guests.
Well, but long enough to get those software issues ruled out. If any 
serious OS would have had problems, somebody would have noticed and 
fixed it.

> I see quite a lot of code in Linux (to pick an example - presumably
> also other OSes) which checks for things by looking at model and
> family number, so I wonder if it's wise to depart a long way from
> CPUIDs which resemble real hardware which has existed.
Yeah, but most of the stuff Linux checks are bugs and workarounds, so I 
am not 100% sure whether it's an advantage. We should be careful with 
adjusting the working default QEMU/KVM has right now.

> We've already seen a problem along these lines, which was the x86
> CPUID_SEP feature not getting used properly, but that was quite well
> hidden, only affecting one application (Skype) on Windows.
> 
> Could it make more sense to, in effect, upgrade the default CPUID
> to Pentium 4 (instead of Pentium Pro) when cores > 1?
OK, OK, I will finally send this patch out (following in another mail).
This is a kvm64 CPU (which should become the new KVM's default, if it 
proves to work well). It looks like a P4 Prescott, that seems to be a 
good base, since it has a decent base line of features and is among the 
first CPUs which are supported by KVM.
If someone has such a real beast (best would be a Pentium 4 662 or other 
Prescotts with x86_64, HT and VT-x), I would love to see a complete 
CPUID dump (including the 0000_0004 subleafs, which x86info omits).

Regards,
Andre.
Andre Przywara - Aug. 25, 2009, 12:21 p.m.
Avi Kivity wrote:
 > Andre Przywara wrote:
>> 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.
Oh, I see now that Alex' Core2Duo (on which QEMU's leaf 4 values are 
based on) has 4 MB of L2-Cache. Although that is not gigantic for Intel 
CPUs, it's certainly too high for many host CPUs. I will lower this 
value to say 1MB or 512K to better match the majority of host. I will 
send a patch together with some more CPUID reworks I am working on.
> 
> btw, does -cpu host use the host cpu cache information?
Good point. It does not, it only deals with leaves 0, 1, 8000_0000 and 
8000_0001. I have created a white list of further CPUID leaves which are 
safe to propagate to the guest and will also send this in a while.

Thanks for these hints,
Andre.

Patch

diff --git a/target-i386/helper.c b/target-i386/helper.c
index dd89885..7de4c07 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -119,7 +119,7 @@  static x86_def_t x86_defs[] = {
 #ifdef TARGET_X86_64
     {
         .name = "qemu64",
-        .level = 2,
+        .level = 4,
         .vendor1 = CPUID_VENDOR_AMD_1,
         .vendor2 = CPUID_VENDOR_AMD_2,
         .vendor3 = CPUID_VENDOR_AMD_3,
@@ -190,7 +190,7 @@  static x86_def_t x86_defs[] = {
 #endif
     {
         .name = "qemu32",
-        .level = 2,
+        .level = 4,
         .family = 6,
         .model = 3,
         .stepping = 3,