On Sun, Nov 29, 2020 at 06:36:17AM +0000, Mike wrote: > And what are you going to return for the other leaf nodes now that > you are claiming a CPUID level of 0x15, on CPUs that are less than > that? > > Eg, if your host supports level 0xb (11), what happens in your diff > if the guest VM requests CPUID leaf node 0x0c (12)? > > It seems you are only handing the single 0x15 case.
That is true. We need to note though that the current situation is not correct either. On CPUs that support ITSC but have a cpuid level lower than 0x15, leaf 0x00 already announces support for leaves up to 0x15, but then vmm returns incorrect values for them. On my laptop its highest supported leaf 0x0B returns eax=0, ebx=0, ecx=0x1a, with the id of the current CPU in edx, so that is what all those extra leaves from 0x0C to 0x15 are currently getting without the patch applied. With the patch applied, most of the extra leaves get zeros, except for the rax=0x0D && rcx=0x00 case, which tries to report the xsave_mask. The rax=0x0B && rcx > 1 does do not seem quite right compared to [1]. [1] https://www.felixcloutier.com/x86/cpuid For some of the leaves as they are documented in [1] when a bit is 0 it means that an extension is unsupported, which makes it a correct default to return zeros, though it has not been established that zeros are a valid response for all of then. Is it more correct to return zeros than to return whatever the host's highest supported leaf returned, as we do now? What do you suggest? Thank you, jh
