On Wed, Jul 20, 2022, Peter Xu wrote:
> Add one new PFN error type to show when we got interrupted when fetching
s/we/KVM
> the PFN due to signal pending.
>
> This prepares KVM to be able to respond to SIGUSR1 (for QEMU that's the
> SIGIPI) even during e.g. handling an userfaultfd page fault.
>
> Signed-off-by: Peter Xu <peterx@xxxxxxxxxx>
> ---
> include/linux/kvm_host.h | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 83cf7fd842e0..06a5b17d3679 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -96,6 +96,7 @@
> #define KVM_PFN_ERR_FAULT (KVM_PFN_ERR_MASK)
> #define KVM_PFN_ERR_HWPOISON (KVM_PFN_ERR_MASK + 1)
> #define KVM_PFN_ERR_RO_FAULT (KVM_PFN_ERR_MASK + 2)
> +#define KVM_PFN_ERR_SIGPENDING (KVM_PFN_ERR_MASK + 3)
>
> /*
> * error pfns indicate that the gfn is in slot but faild to
> @@ -106,6 +107,16 @@ static inline bool is_error_pfn(kvm_pfn_t pfn)
> return !!(pfn & KVM_PFN_ERR_MASK);
> }
>
> +/*
> + * When KVM_PFN_ERR_SIGPENDING returned, it means we're interrupted during
> + * fetching the PFN (a signal might have arrived), we may want to retry at
Please avoid "we". Tthe first "we're" can refer to KVM and/or the kernel,
whereas the second is a weird mix of KVM and userspace (KVM exits to userspace,
but it's userspace's decision whether or not to retry).
Easiest thing is to avoid the "we" entirely and not speculate on what may happen.
E.g.
/*
* KVM_PFN_ERR_SIGPENDING indicates that fetching the PFN was interrupted by a
* pending signal. Note, the signal may or may not be fatal.
*/
> + * some later point and kick the userspace to handle the signal.
> + */
> +static inline bool is_sigpending_pfn(kvm_pfn_t pfn)
> +{
> + return pfn == KVM_PFN_ERR_SIGPENDING;
> +}
> +
> /*
> * error_noslot pfns indicate that the gfn can not be
> * translated to pfn - it is not in slot or failed to
> --
> 2.32.0
>
