| Message ID | 1250689362-11067-3-git-send-email-andre.przywara@amd.com |
|---|---|
| State | Superseded |
| Headers | show |
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.
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.
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?
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
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.
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.
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,
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(-)