On 3/3/2020 12:12 PM, Sean Christopherson wrote:
On Tue, Mar 03, 2020 at 12:02:39PM +0800, Xiaoyao Li wrote:
On 3/3/2020 11:45 AM, Sean Christopherson wrote:
On Tue, Mar 03, 2020 at 10:27:47AM +0800, Xiaoyao Li wrote:
Sorry I cannot catch you. Why it's a violation of Intel's SDM?
The case being discussed above would look like:
KVM CPUID Entries:
Function Index Output
0x00000000 0x00: eax=0x0000000b ebx=0x756e6547 ecx=0x6c65746e edx=0x49656e69
0x00000001 0x00: eax=0x000906ea ebx=0x03000800 ecx=0xfffa3223 edx=0x0f8bfbff
0x00000002 0x00: eax=0x00000001 ebx=0x00000000 ecx=0x0000004d edx=0x002c307d
0x00000003 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000
0x00000004 0x00: eax=0x00000121 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001
0x00000004 0x01: eax=0x00000122 ebx=0x01c0003f ecx=0x0000003f edx=0x00000001
0x00000004 0x02: eax=0x00000143 ebx=0x03c0003f ecx=0x00000fff edx=0x00000001
0x00000004 0x03: eax=0x00000163 ebx=0x03c0003f ecx=0x00003fff edx=0x00000006
0x00000005 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000003 edx=0x00000000
0x00000006 0x00: eax=0x00000004 ebx=0x00000000 ecx=0x00000000 edx=0x00000000
0x00000007 0x00: eax=0x00000000 ebx=0x009c4fbb ecx=0x00000004 edx=0x84000000
0x00000008 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000
0x00000009 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000
0x0000000a 0x00: eax=0x07300402 ebx=0x00000000 ecx=0x00000000 edx=0x00000603
--> MISSING CPUID.0xB.0
0x0000000b 0x01: eax=0x00000000 ebx=0x00000001 ecx=0x00000201 edx=0x00000003
CPUID.0xB.0 does not exist, so output.ECX=0, which indicates an invalid
level-type.
The SDM states (for CPUID.0xB):
If an input value n in ECX returns the invalid level-type of 0 in ECX[15:8],
other input values with ECX > n also return 0 in ECX[15:8]
That means returning a valid level-type in CPUID.0xB.1 as above violates
the SDM's definition of how leaf 0xB works. I'm arguing we can ignore the
adjustments that would be done on output.E{C,D} for an out of range leaf
because the model is bogus.
Right.
So we'd better do something in KVM_SET_CPUID* , to avoid userspace set bogus
cpuid.
Supposing the max basic is 0x1f, and it queries cpuid(0x20, 0x5),
it should return cpuid(0x1f, 0x5).
But based on this patch, it returns all zeros.
Have you tested the patch, or is your comment based on the above discussion
and/or code inspection? Honest question, because I've thoroughly tested
the above scenario and it works as you describe, but now I'm worried I
completely botched my testing.
No, I didn't test.
Leaf 0xB and 0x1f are special cases when they are the maximum basic leaf,
because no matter what subleaf is, there is always a non-zero E[CX,DX].
If cpuid.0 returns maximum basic leaf as 0xB/0x1F, when queried leaf is
greater, it should always return a non-zero value.
Yes, and that's userspace's responsibility to not screw up. E.g. if
userspace didn't create CPUID.0xB.0 (as above) then it's not KVM's fault
for returning zeros when the guest executes CPUID.0xB.0.
But this needs userspace to create all the subleaf of 0xB/0x1F. with a
correct userspace, for example, it only creates one more subleaf of
0xB/0x1F to indicate from this subleaf, no valid level-type anymore.
So when maximum basic leaf is 0x1f, cpuid(0x20, bigger than the first
invalid subleaf created by userspace) returns all-zero.
