Stephane > > >There may be some propagation delay yet you, supposedly, do not suffer > > >from masked > > >interrupt windows. Also something to watch out for is that when you restore > > >you must make sure that msrs upper bits are set to 1. Otherwise you may > > >trigger > > >unvoluntary interrupts. > > > > I'm not sure which msrs you're referring to. The only perfmon msr > > reserved bits I see in the documentation that need to be set to 1 are > > bits 16 and 17 of CCCR, but I've actually only been considering Core > > and Core 2 processors with the simplified perfmon design that has just > > IA32_PERFEVTSEL and IA32_PMC. These are the only two msrs I'm saving > > and restoring. I save them to the VM-exit guest-state area and clear > > them for root mode and then restore them from the guest-state area on > > resume. > > Yes, I am talking about IA32_PMC0/1. You need to ensure that the upper > bits (32-63) are always set to 1 if you want to get an interrupt. > If I recall I also had to fixup (force upper bits to 1) the VT-saved PMC0/PMC1 > to avoid getting a spurious interrupt on VM-entry. >
I assume you mean bits 40-63 since the counters are 40-bit, although I'm still not sure about forcing them to 1. The steps I take are to set a 64-bit variable to a negative value of one greater than I want to trigger on. For example, if I want to trigger on 100 events, I set a 64-bit variable to -99. Before I do a VM resume, I set the VM-entry load bitmap to that value (as well as program the PERFEVTSEL entry load bitmap to enable counting and PMI). I also have the exit store bitmap clear the PERFEVTSEL to stop counting on exit. If I then look at the PMC value from the save area after the next exit, however, I find the top 14-bit are cleared (even if it didn't overflow yet). Based on this, I assumed it was because the counter is 40-bit as it was in the Netburst architecture. I believe if I forced the top bits back to one, they would just be cleared again when the h/w copied the value into the actual 40-bit msr. I'm interested to find out if you are seeing the same thing with regards to NMI's in root mode, though. If you already have all this working, all you should have to do is program the LVT to deliver an NMI and stop the KVM handler from making the INT2 call in its handler. Then, if you are seeing NMI's in root mode, you'll get lots of "Dazed and confused" messages from the kernel. > > > > Even with this, I get a fairly large number of NMI's that occur in > > root mode. Theoretically, the counter should be disabled when the exit > > occurs and overflows shouldn't occur. I think if the implementation is > > really that poor, it would be very difficult to use them for assessing > > guest performance. I'm guessing I'm just missing something and they do > > work better than that. > > The counter is disabled only if you clear it. the hardware does not > do this by default for you. For that you can use the VM-entry load MSR > bitmap. In my current test code, I do just that. You save on VM-exit, > load zero into PERFEVTSEL0 on VM-exit and on VM-entry you restore PERFEVTSEL0. > > -- > -Stephane > Thanks, Casey ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
