Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v2)

[Gleb Natapov <gleb@redhat.com>]

On Thu, Dec 02, 2010 at 02:51:51PM -0600, Anthony Liguori wrote:
> On 12/02/2010 02:12 PM, Marcelo Tosatti wrote:
> >>>>  	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.
> 
> But you can't inject an exception into a guest while the VMCS is
> active, can you?  So the guest takes an exit while in the hlt
> instruction but that's no different than if the guest has been
> interrupted because of hlt exiting.
> 
Async PF completion do not kick vcpu out of a guest mode. It wakes vcpu
only if it is waiting on waitqueue. It was done to not generate
unnecessary overhead.

> >You'd have to handle this situation on event injection, vmentry fails
> >otherwise. Or perhaps clear HLT state on vmexit and vmentry.
> 
> So this works today because on a hlt exit, emulate_halt() will clear
> the the HLT state which then puts the the vcpu into a state where it
> can receive an exception injection?
> 
> Regards,
> 
> Anthony Liguori
> 
> >>>  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.
> >
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
			Gleb.