On 2011-05-05 10:33, Avi Kivity wrote: > On 05/05/2011 11:27 AM, Jan Kiszka wrote: >>> >>> 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? > > Do you mean cpu specific as in smp or cpu specific as in cpu model? Yep. > > If the former, we simply do the reset operation per-cpu. It's the > natural thing anyway. Quite wasteful /wrt to memory given that the majority will be identical. > >>> 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. > > Great, thanks. > >> Nevertheless, the qemu-kvm code is already unneeded today and can safely >> be removed IMHO. > > I don't follow? Won't it cause a regression? Not at all. We use the "individual care" pattern upstream now, specifically for those MSRs (kvmclock) for which the qemu-kvm code was introduced. > > Of course, if we get a patch soon no one will ever see the regression so > we can apply the series. I will still require the usual testing and merging round via upstream and back. Not sure when I'll be able to work on it, probably not the next days. 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
