On 05/05/2011 11:11 AM, Jan Kiszka wrote:
On 2011-05-05 10:08, Avi Kivity wrote:
> On 05/04/2011 10:43 PM, Jan Kiszka wrote:
>> From: Jan Kiszka<jan.kiszka@xxxxxxxxxxx>
>>
>> Paravirtual MSRs are properly cleared on reset now, and blindly clearing
>> the rest is questionable anyway (better address those one by one,
>> re-initializing their backing CPU state fields).
>>
>
> This can introduce a regression when new paravirtual MSRs are added.
You mean MSRs already included or future ones?
Future ones.
> So
> we either need to port this, or query the reset state from the kernel
> immediately after creating the vcpu and saving it.
Can't completely follow what you mean.
My general point remains: Every MSR requires individual care, not blind
overwriting like qemu-kvm does. So the person contributing a new MSR,
real or pv, has to tackle this aspect, and we need to review the code in
this regard.
It's a trick to avoid needing individual care.
1. Call KVM_CREATE_VCPU. This causes all MSRs to be initialized to
their power-on reset values.
2. Issue KVM_GET_MSR_LIST, and then KVM_GET_MSRS to read all MSRs.
Stash them all in safe places - the ones known to qemu but also the
unknown ones. Qemu may use its own values for the MSRs it knows about
(for example if different cpu models have different power-on values)
3. On reset, issue KVM_SET_MSRS with the MSR values obtained in step 2.
The result is forward and backwards compatibility without lockstepping
qemu and kvm.
--
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
