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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
