Re: [PATCH] i386: wire up MSR_IA32_MISC_ENABLE

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]

On 2011-10-04 19:21, Avi Kivity wrote:
> 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.

Pre-Pentiums don't have instructions to access them as well, so that
doesn't cause any harm.

> 
> (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)

Right. If this MSR is not the first bogus one on AMD, we can do this
later. If it is, it should be done first.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]