Paolo Bonzini pbonzini@redhat.com writes:
On 08/04/20 01:21, Thomas Gleixner wrote:
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.
Interrupts can be delayed by TPR or STI/MOV SS interrupt window, async page faults cannot (again, not the page-ready kind).
Can we pretty please stop using the term async page fault? It's just wrong and causes more confusion than anything else.
What this does is really what I called Opportunistic Make Guest Do Other Stuff. And it has neither true exception nor true interrupt semantics.
It's a software event which is injected into the guest to let the guest do something else than waiting for the actual #PF cause to be resolved. It's part of a software protocol between host and guest.
And it comes with restrictions:
The Do Other Stuff event can only be delivered when guest IF=1.
If guest IF=0 then the host has to suspend the guest until the situation is resolved.
The 'Situation resolved' event must also wait for a guest IF=1 slot.
Page-not-present async page faults are almost a perfect match for the hardware use of #VE (and it might even be possible to let the processor deliver the exceptions). There are other advantages:
- the only real problem with using #PF (with or without
KVM_ASYNC_PF_SEND_ALWAYS) seems to be the NMI reentrancy issue, which would not be there for #VE.
- #VE are combined the right way with other exceptions (the
benign/contributory/pagefault stuff)
- adjusting KVM and Linux to use #VE instead of #PF would be less than
100 lines of code.
If you just want to solve Viveks problem, then its good enough. I.e. the file truncation turns the EPT entries into #VE convertible entries and the guest #VE handler can figure it out. This one can be injected directly by the hardware, i.e. you don't need a VMEXIT.
If you want the opportunistic do other stuff mechanism, then #VE has exactly the same problems as the existing async "PF". It's not magicaly making that go away.
One possible solution might be to make all recoverable EPT entries convertible and let the HW inject #VE for those.
So the #VE handler in the guest would have to do:
if (!recoverable()) { if (user_mode) send_signal(); else if (!fixup_exception()) die_hard(); goto done; }
store_ve_info_in_pv_page();
if (!user_mode(regs) || !preemptible()) { hypercall_resolve_ept(can_continue = false); } else { init_completion(); hypercall_resolve_ept(can_continue = true); wait_for_completion(); }
or something like that.
The hypercall to resolve the EPT fail on the host acts on the can_continue argument.
If false, it suspends the guest vCPU and only returns when done.
If true it kicks the resolve process and returns to the guest which suspends the task and tries to do something else.
The wakeup side needs to be a regular interrupt and cannot go through #VE.
Thanks,
tglx