Re: [Qemu-devel] Re: [PATCH 3/4] mask out forbidden cpuid features with kvm ioctl

[Glauber Costa <glommer@gmail.com>]

On Thu, Jan 29, 2009 at 6:50 PM, Anthony Liguori <aliguori@us.ibm.com> wrote:
> Glauber Costa wrote:
>>
>> KVM has a (so far unused) ioctl to inform userspace
>> about supported cpuid bits in the current host.
>>
>> The lack of this kind of checking can lead to bugs in which
>> a cpuid bit is exposed but not supported by the host kernel
>> (an example is fedora bug
>> https://bugzilla.redhat.com/show_bug.cgi?id=481274)
>>
>> The current host_cpuid code is replaced by this general check.
>>
>> Signed-off-by: Glauber Costa <glommer@redhat.com>
>>
>
> So what do we do about live migration?  Does KVM mask a set of bits
> unconditionally?  Before, we were masking unconditionally which should
> insulate migration reasonable well.
>

Just to be clear:

Are you raising the flag against the lack of unconditional mask only,
or about it + querying kvm.ko for supported bits?

I think we need to query it anyway, because calling cpuid will only
give you information about your cpu, and querying the kernel will give
you this, plus information about what the kernel supports (think of
the 32 bit kernel on 64 bit hardware case), plus whatever else kvm
wants to mask for whatever reason.

About migration, I was under the impression that the solution we were
going towards was based on defining a kvm machine type that would
contain a common set of features among the hosts involved. If this is
the case, I believe we don't need to unconditionally mask out
anything, since the features we expose in the machine type won't even
have the problematic features.

If this is not the case, I'm fine with redoing this patch with
querying kvm.ko + unconditional mask of potentially problematic
features.

-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."