On 10/04/2011 07:14 PM, Jan Kiszka wrote:
>
>> > +
>> > +static const VMStateDescription vmstate_msr_ia32_misc_enable = {
>> > + .name = "cpu/msr_ia32_misc_enable",
>> > + .version_id = 1,
>> > + .minimum_version_id = 1,
>> > + .minimum_version_id_old = 1,
>> > + .fields = (VMStateField []) {
>> > + VMSTATE_UINT64(msr_ia32_misc_enable, CPUState),
>> > + VMSTATE_END_OF_LIST()
>> > + }
>> > +};
>> > +
>>
>> We are about to bump the CPU_SAVE_VERSION for the sake of APIC deadline
>> timer, so you can jump on that train and avoid this subsection.
>
> Must we do that? Considering that no guest will use the deadline timer,
> it seems to be an excellent candidates for subsections.
I don't know, it was sent out for pull like that. And I thought
subsections are still broken, aren't they?
Well let's fix subsections instead of disabling migration to older versions.
>>
>> This MSR is Intel-specific, isn't it? Then I guess it should be limited
>> to Intel CPU types.
>
> It's an "architectural MSR" that is only available on some Intel
> models. Either we do a full cpuid qualification of accessible MSRs (and
> bits within MSRs), or not. Qualifying just by vendor ID is pointless.
Given that, when in conflict, we rather model after AMD than Intel for
TCG, I would hesitate to expose this by default. Or are there
precedences already?
Practically all MSRs. i486 doesn't have any, IIRC, for example.
(and given this MSR has no effect, the only difference it makes to
guests is the #GP we take or not; still it may be worthwhile to
construct some table-driven thing to allow or reject MSR accesses, both
for kvm and qemu)
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
