Casey, On Tue, Apr 03, 2007 at 10:46:38PM -0400, Casey Jeffery wrote: > Stephane, > > I'm glad you found this; I thought I was going to have to repost while > actually remembering to change the subject line. > Someone else pointed me to your message. The title was indeed misleading.
> >On Wed, Mar 28, 2007 at 01:02:47PM -0400, Casey Jeffery wrote: > >> I was messing around with using the perf counters a couple weeks ago > >> as a way to get deterministic exits in the instruction stream of the > >> guest. I used the h/w msr save/restore area to disable the counters > >> and save the values on guest exit and restore them on entry. I also > >> set up the LVT to deliver NMI's on overflow. > >> > >You mean the host APIC LVT vector? > Yes, FEE0 0340 in the host. Yes, that is the one. > >> This basically worked as expected, but I never got around the problem > >> of inconsistent NMI delivery. A large majority of the time the NMI > >> would be delivered in non-root mode and a vmexit would occur, as > >> expected. Occasionally, though the NMI is delivered in root mode. It > >> seems if the overflow occurs near the time a vmexit occurs for some > >> other reason, the NMI takes long enough to propagate that it's > >> delivered in root mode. > >> > >In my tests, I have setup perfmon to use a regular interrupt vector (0xee). > >I have not yet played with NMI. This is in general more difficult to > >handle, > >although, from Avi's comments, it looks like I could have caught the > >interrupt > >more easily in KVM. > > I haven't tried anything other than NMI's and wasn't aware of the > ack-on-exit bit, either. I've just put the call to the handler in the > handler_exception() function in vmx.c. This is where I expect it to > end up if the NMI occurs while in non-root mode. > With regular interrupt, you end up in handle_external_interrupt() but only AFTER the host kernel as serviced the interrupt. > > > >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. > > 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 ------------------------------------------------------------------------- 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
