On Wed, 24 Jul 2024 12:13:28 +0100 John Levon <john.le...@nutanix.com> wrote:
> On Wed, Jul 24, 2024 at 03:59:29PM +0530, Manish wrote: > > > > > Leaf 0x1f is superset of 0xb, so it makes sense to set 0x1f equivalent > > > > to 0xb by default and workaround windows issue.> > > > > This change adds a > > > > new property 'cpuid-0x1f-enforce' to set leaf 0x1f equivalent to 0xb in > > > > case extended CPU topology is not configured and behave as before > > > > otherwise. > > > repeating question > > > why we need to use extra property instead of just adding 0x1f leaf for > > > CPU models > > > that supposed to have it? > > > > As i mentioned in earlier response. "Windows expects it only when we have > > set max cpuid level greater than or equal to 0x1f. I mean if it is exposed > > it should not be all zeros. SapphireRapids CPU definition raised cpuid level > > to 0x20, so we starting seeing it with SapphireRapids." > > > > Windows does not expect 0x1f to be present for any CPU model. But if it is > > exposed to the guest, it expects non-zero values. > > I think Igor is suggesting: > > - leave x86_cpu_expand_features() alone completely yep, drop that if possible > - change the 0x1f handling to always report topology i.e. never report all > zeroes Do this but only for CPU models that have this leaf per spec, to avoid live migration issues create a new version of CPU model, so it would apply only for new version. This way older versions and migration won't be affected. > > Yes, that would mean that if something requests 0x1f leaf even though the max > leaf is lower, they'd get data back, but it's not clear why that'd be an > issue? > > regards > john >
