On Tue, 2010-06-22 at 09:58 +0200, Jes Sorensen wrote: > On 06/22/10 09:47, Zhang, Yanmin wrote: > > On Tue, 2010-06-22 at 09:14 +0200, Jes Sorensen wrote: > >> On 06/22/10 03:49, Zhang, Yanmin wrote: > >>> On Mon, 2010-06-21 at 14:45 +0300, Avi Kivity wrote: > >>> So I think above discussion is around how to expose PMU hardware to guest os. I will > >>> also check this method after the para virt interface is done. > >> > >> You should be able to expose the counters as read-only to the guest. KVM > >> allows you to specify whether or not a guest has read, write or > >> read/write access. If you allowed read access of the counters that would > >> safe a fair bit of hyper calls. > > Thanks. KVM is good in register access permission configuration. But things are not so > > simple like that if we consider real running environment. Host kernel might schedule > > guest os vcpu thread to other cpus, or other non-kvm processes might preempt the vcpu > > thread on this cpu. > > > > To support such capability you said, we have to implement the direct exposition of PMU > > hardware to guest os eventually. > > If the guest is rescheduled to another CPU, or you get a preemption, you > have a VMEXIT. The vcpu thread will not migrate while it is running, so > you can handle it while the the VMEXIT is being serviced. > > Exposing the counters read-only would save a lot of overhead for sure. > >> Question is if it is safe to drop overflow support? > > Not safe. One of PMU hardware design objectives is to use interrupt or NMI to notify > > software when event counter overflows. Without overflow support, software need poll > > the PMU registers looply. That is not good and consumes more cpu resources. > > Here is an idea, how about having the overflow NMI in the host trigger a > flag that causes the PMU register read to trap and get special handling? > That way you could propagate the overflow back down to the guest. That doesn't resolve the issue that guest os software has to poll register. -- 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
