On 2011-05-05 10:16, Avi Kivity wrote: > 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. Almost all: Which ones are CPU specific like the APIC_BASE? > 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. OK, sounds good. I will work out a patch for uq/master. Nevertheless, the qemu-kvm code is already unneeded today and can safely be removed IMHO. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
