From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFT] mmu optimizations branch Date: Tue, 02 Jan 2007 19:09:01 +0200 Message-ID: <459A91AD.9030309@qumranet.com> References: <4598E33B.608@qumranet.com> <20070102161117.GA3306@elte.hu> <459A8909.7020600@qumranet.com> <20070102170212.GB25271@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel Return-path: To: Ingo Molnar In-Reply-To: <20070102170212.GB25271-X9Un+BFzKDI@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Ingo Molnar wrote: > * Avi Kivity wrote: > > >>> unfortunately 0xc011f7f3 is in native_write_msr(), which isnt very >>> helpful. (i have CONFIG_PARAVIRT enabled in the -rt guest and host >>> kernels) But the MSR values suggest that this is the NMI watchdog >>> thing again, trying to program MSR_ARCH_PERFMON_EVENTSEL0 and >>> MSR_ARCH_PERFMON_PERFCTR0, but this time Linux recovered due to a >>> more robust MSR handling. The guest disabled the NMI watchdog with: >>> >>> Testing NMI watchdog ... CPU#0: NMI appears to be stuck (0->0)! >>> >>> the FC6 installer hang that i saw with earlier MMU-branch snapshots >>> is fixed. >>> >> Good. Handling the counter well would have been very difficult, >> especially if attempting to support cross migration. >> > > as far as the NMI watchdog goes, it's in fact better to keep it disabled > this way - it's not like the guest context could 'lock up' in an > undebuggable way. Any NMI activity in the guest context would be pretty > pointless. I'd suggest simulating a non-working performance counter: > i.e. dont inject a #GPF when doing the wrmsr, and maybe preserve the > values that were written into the MSR register, but otherwise dont try > to implement the functionality by injecting NMIs. Worst-case this could > result in user-space debugging tools seeing non-working > performance-counter functionality. > > My worry is that when emulating an msr incorrectly, software can fail without any clue as to what went wrong. I'll add the emulation as you suggest bug with a printk() to warn that we're bending the rules. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- 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