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