qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] i386: wire up MSR_IA32_MISC_ENABLE


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH] i386: wire up MSR_IA32_MISC_ENABLE
Date: Tue, 04 Oct 2011 19:24:58 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]