On 08/27/2010 07:43 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 08/27/2010 05:13 PM, Jan Kiszka wrote:
I forgot them already. What was that, exception during IRET?
Exception during IRET or any instruction under the interrupt shadow will
push the TF we set to step over this issue on the guest stack. We do not
intercept all the possible exceptions, so we can leak TF. Moreover,
multiplexing TF users is currently imperfect on AMD but, before fixing
that, we have to think about the approach in general.
Thanks. I think those are all solvable. The key IMO is to take a state
based approach to host bits - instead of setting or clearing a bit in
response to an event, use the event as a trigger for recalculation of
the bit's value. This works for bits which have multiple uses, and for
recovery from KVM_SET_*. For guest bits which are needed by the host we
also have a working approach - when the bit is overloaded, trap all
instructions that can see it, as in CR0.TS.
It may take some work but I think we can achieve 100% accuracy without
making the code unmaintainable.
Besides making TF usage robust against multiple users, including the
guest itself, my complexity concern is first of all about preventing its
leakage. We will have to trap _all_ exceptions and properly remove TF
from the guest state.
Note we already trap all exceptions on Intel when virtualizing real mode
via vm86.
And then there is a potential performance price to pay (yes, accuracy
should come first): If the guest uses NMIs for profiles, thus at a
significant rate, AMD processors force us to exit twice per NMI return -
independent of the fact if there is another NMI pending or not.
Doesn't worry me too much. NMI rate will be limited or
program-under-test performance will suffer. 10K vs 20K exits/sec is
substantial, but not worth worrying about for this fairly rare use case.
I'm more concerned that we don't push VMLOAD/VMSAVE to the heavyweight
exit path, and that we don't use the svm interrupt queue (that could
reduce 10% of the exits on normal interrupts).
--
error compiling committee.c: too many arguments to function
--
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
