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.
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
