unconditional CPUID propagation?
Hi,
while looking through the code I found commitf79116867ec80ed5d1d10043a3fd9ac8afd182c1 (upstream QEMU: enable SMEP) which unconditionally propagates the bits from CPUID leaf 0x7 to the guest. Though there is the KVM module in the line, this currently whitelists three feature bits.
Doesn't that break migration? The result of the CPUID instruction the guess issues only depends on the host and the KVM module's policy, not on the CPU model QEMU uses. So I guess migrating from a newer CPU to an older one breaks despite a rather conservative CPU model has been chosen intentionally by the user. The same is probably true for the VIA CPUID leaf.
Is that considered OK now or is that a bug? Shall the new feature bits be made known to QEMU like the other ones on only enabled explicitly (+smep) or by -cpu host? I can make a patch for that if that is the right way to address this.
Regards,
Andre.
Signature · 3 lines
Andre Przywara AMD-OSRC (Dresden) Tel: x29712
Quoted 14 lines · Andre Przywara
Hi,
while looking through the code I found commit
f79116867ec80ed5d1d10043a3fd9ac8afd182c1(upstream QEMU: enable SMEP) which unconditionally propagates the bits from CPUID leaf0x7to the guest. Though there is the KVM module in the line, this currently whitelists three feature bits.
Doesn't that break migration? The result of the CPUID instruction the guess issues only depends on the host and the KVM module's policy, not on the CPU model QEMU uses. So I guess migrating from a newer CPU to an older one breaks despite a rather conservative CPU model has been chosen intentionally by the user.
The same is probably true for the VIA CPUID leaf.
Quoted 4 lines
Is that considered OK now or is that a bug? Shall the new feature bits be made known to QEMU like the other ones on only enabled explicitly (+smep) or by -cpu host?
I can make a patch for that if that is the right way to address this.
Or if the CPU type supports it, yes.