Hi, I think I've tracked down the bug that causes
"KVM_GET_SUPPORTED_CPUID failed: Argument list too long" errors when
using the kvm tool. Basically, this (possibly squished) code seems to
be to blame:
case 0xd: {
int i;
entry->flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
for (i = 1; *nent < maxnent && i < 64; ++i) {
if (entry[i].eax == 0)
continue;
do_cpuid_1_ent(&entry[i], function, i);
entry[i].flags |=
KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
++*nent;
}
break;
}
You can see there's a check whether entry[i].eax is 0, but it isn't
until the next line that entry[i] is actually filled in. That means
that whether or not an entry is filled in for the 0xd function is
essentially random, and that can lead to the loss of valid entries. It
also means that nent may be incremented too often, and since all 64
entries are iterated over, that can fill up the available storage and
cause that error.
I tested my theory by commenting out the if (100% failure rate) and
moving it after do_cpuid_1_ent (100% success rate). Since this is a
non-deterministic failure that isn't really conclusive, but I'm fairly
confident my fix is correct. I don't know exactly what your procedure
is for submitting patches, but one is attached.
Gabe
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 77c9d86..35d7ae0 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2414,9 +2414,9 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
entry->flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
for (i = 1; *nent < maxnent && i < 64; ++i) {
+ do_cpuid_1_ent(&entry[i], function, i);
if (entry[i].eax == 0)
continue;
- do_cpuid_1_ent(&entry[i], function, i);
entry[i].flags |=
KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
++*nent;
