From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v2) Date: Thu, 2 Dec 2010 18:12:23 -0200 Message-ID: <20101202201223.GA31316@amt.cnet> References: <1291298357-5695-1-git-send-email-aliguori@us.ibm.com> <20101202173733.GA26342@amt.cnet> <4CF7EE63.40209@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, Avi Kivity , Chris Wright , Srivatsa Vaddagiri To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:30798 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757144Ab0LBUlS (ORCPT ); Thu, 2 Dec 2010 15:41:18 -0500 Content-Disposition: inline In-Reply-To: <4CF7EE63.40209@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: > >> opt = CPU_BASED_TPR_SHADOW | > >> CPU_BASED_USE_MSR_BITMAPS | > >> CPU_BASED_ACTIVATE_SECONDARY_CONTROLS; > >>-- > >>1.7.0.4 > >Breaks async PF (see "checks on guest state"), > > Sorry, I don't follow what you mean here. Can you elaborate? VCPU in HLT state only allows injection of certain events that would be delivered on HLT. #PF is not one of them. You'd have to handle this situation on event injection, vmentry fails otherwise. Or perhaps clear HLT state on vmexit and vmentry. > > timer reinjection > >probably. > > Timer reinjection will continue to work as expected. If a guest is > halting an external interrupt is delivered (by a timer), the guest > will still exit as expected. > > I can think of anything that would be functionally correct and still > depend on getting hlt exits because ultimately, a guest never > actually has to do a hlt (and certainly there are guests that > won't). LAPIC pending timer events will be reinjected on entry path, if accumulated. So they depend on any exit. If you disable HLT-exiting, delay will increase. OK, maybe thats irrelevant. > > It should be possible to achieve determinism with > >a scheduler policy? > > If the desire is the ultimate desire is to have the guests be > scheduled in a non-work conserving fashion, I can't see a more > direct approach that to simply not have the guests yield (which is > ultimately what hlt trapping does). > > Anything the scheduler would do is after the fact and probably based > on inference about why the yield. Another issue is you ignore the hosts idea of the best way to sleep (ACPI, or whatever). And handling inactive HLT state (which was never enabled) can be painful.