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.
I'd really like to avoid the timer. But I forgot all the details around
this, I'll have to re-learn them so I can actually compare the two options.
Hope the above helps you to get on track, otherwise drop more questions.
Also putting Joerg on CC (in the futile hope that the longer the CC list
is, the lesser the pain becomes for each individual).
I think I got it. And I also think we need to start documenting these
invariants, to make it easier for people to see the method in all that
chaos.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
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
