On 2011-05-05 10:53, Avi Kivity wrote: > On 05/05/2011 11:44 AM, Jan Kiszka wrote: >> 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. > > Doh. > >> > >> > 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. > > We're talking a few hundred bytes per cpu. If you want to save memory, > look at the PhysPageDesc array, it takes up 0.4% of guest memory, so 4MB > for a 1GB guest. I know (that's fixable, BTW). But that should not excuse needless memory wasting elsewhere. > >> >> 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. > > I mean a future regression with current+patch qemu and a new kernel. For sane scenarios, such a combination should never expose new (ie. unknown from qemu's POV) MSRs to the guest. Thus not clearing them cannot cause any harm. BTW, you also do not know if 0 will be the right reset value for these to-be-invented MSRs. That could cause regression as well. > >> > >> > 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. > > If you can do it within a couple of weeks or so that should be fine. > We'll see, but I still do not share your concern regarding future regressions when removing the fragile reset code. 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
