[PATCH 0/1] KVM: arm64: Make kvm_s2_fault_pin_pfn() fault-in interruptible

[Jia He <justin.he@arm.com>]

Hi,

I hit this while looking at long vCPU hung-task stalls with nested
virtualization enabled.

The vCPU was blocked in the fault-in path on a userspace folio which was
under migration:

  __kvm_faultin_pfn()
    -> get_user_pages_unlocked()
      -> do_swap_page()              /* PTE is a migration entry */
        -> migration_entry_wait()
           set_current_state(TASK_UNINTERRUPTIBLE);
           io_schedule();            /* no timeout */

At this point the vCPU cannot observe a pending signal. If userspace is
trying to tear down the VM, the vCPU thread can still remain stuck until
migration finishes and the folio lock is released.

Nested virtualization makes this much easier to hit. The migration path
can hold the folio lock while the MMU notifier runs kvm_nested_s2_unmap(),
and that can be expensive today since it may walk all active shadow
stage-2s. So the long delay is really caused by the unmap/migration side;
the vCPU is just waiting for it to finish.

This patch does not try to make that unmap path cheaper. That is a
separate issue, and range-aware shadow stage-2 unmap work, such as
Wei-Lin Chang's "KVM: arm64: nv: Avoid full shadow s2 unmap" series,
is aimed at that problem.

What this patch does is narrower: use FOLL_INTERRUPTIBLE when faulting in
the userspace page for the arm64 stage-2 fault path. If the vCPU thread
has a pending signal, GUP can return and KVM can leave KVM_RUN through the
normal KVM_EXIT_INTR path. If there is no pending signal, the behaviour is
unchanged.

Jia He (1):
  KVM: arm64: Make kvm_s2_fault_pin_pfn() fault-in interruptible

 arch/arm64/kvm/mmu.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

-- 
2.34.1