Sean Christopherson <seanjc@xxxxxxxxxx> writes: > On Wed, Jan 26, 2022, Vitaly Kuznetsov wrote: >> Joe Perches <joe@xxxxxxxxxxx> writes: >> >> > On Mon, 2022-01-24 at 11:36 +0100, Vitaly Kuznetsov wrote: >> >> kvm_cpuid_check_equal() should also check .flags equality but instead >> >> of adding it to the existing check, just switch to using memcmp() for >> >> the whole 'struct kvm_cpuid_entry2'. >> > >> > Is the struct padding guaranteed to be identical ? >> > >> >> Well, yes (or we're all doomeed): >> - 'struct kvm_cpuid_entry2' is part of KVM userspace ABI, it is supposed >> to be stable. >> - Here we compare structs which come from the same userspace during one >> session (vCPU fd stays open), I can't imagine how structure layout can >> change on-the-fly. > > I'm pretty sure Joe was asking if the contents of the padding field would be > identical, i.e. if KVM can guarnatee there won't be false positives on > mismatches, Ah, sorry, I thought about structure layout. Generally, there's no guarantee the content of the padding will be the same in the KVM_SET_CPUID2 case as we vmemdup_user() what userspace VMM gives us. > which is the same reason Paolo passed on this patch. Though I still think we > should roll the dice :-) Well, so far we've only identified CPU (re-)hotplug by reusing an existing vCPU fd as a broken use-case and it may happen that QEMU is the only VMM which does that (and memcmp() approach works for it) ... but who know what's out there) -- Vitaly
