> >> 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. -- 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
