Paolo Bonzini <pbonzini@xxxxxxxxxx> writes:
> On 07/04/20 22:20, Thomas Gleixner wrote:
>>>> Havind said that, I thought disabling interrupts does not mask exceptions.
>>>> So page fault exception should have been delivered even with interrupts
>>>> disabled. Is that correct? May be there was no vm exit/entry during
>>>> those 10 seconds and that's why.
>> No. Async PF is not a real exception. It has interrupt semantics and it
>> can only be injected when the guest has interrupts enabled. It's bad
>> design.
>
> Page-ready async PF has interrupt semantics.
>
> Page-not-present async PF however does not have interrupt semantics, it
> has to be injected immediately or not at all (falling back to host page
> fault in the latter case).
If interrupts are disabled in the guest then it is NOT injected and the
guest is suspended. So it HAS interrupt semantics. Conditional ones,
i.e. if interrupts are disabled, bail, if not then inject it.
But that does not make it an exception by any means.
It never should have been hooked to #PF in the first place and it never
should have been named that way. The functionality is to opportunisticly
tell the guest to do some other stuff.
So the proper name for this seperate interrupt vector would be:
VECTOR_OMG_DOS - Opportunisticly Make Guest Do Other Stuff
and the counter part
VECTOR_STOP_DOS - Stop Doing Other Stuff
> So page-not-present async PF definitely needs to be an exception, this
> is independent of whether it can be injected when IF=0.
That wants to be a straight #PF. See my reply to Andy.
> Hypervisors do not have any reserved exception vector, and must use
> vectors up to 31, which is why I believe #PF was used in the first place
> (though that predates my involvement in KVM by a few years).
No. That was just bad taste or something worse. It has nothing to do
with exceptions, see above. Stop proliferating the confusion.
> These days, #VE would be a much better exception to use instead (and
> it also has a defined mechanism to avoid reentrancy).
#VE is not going to solve anything.
The idea of OMG_DOS is to (opportunisticly) avoid that the guest (and
perhaps host) sit idle waiting for I/O until the fault has been
resolved. That makes sense as there might be enough other stuff to do
which does not depend on that particular page. If not then fine, the
guest will go idle.
Thanks,
tglx
