Re: [PATCH v2 3/3] kvm/x86: Allow to respond to generic signals during slow page faults

[Peter Xu <peterx@redhat.com>]

On Tue, Aug 16, 2022 at 03:51:16PM -0700, David Matlack wrote:
> On Tue, Aug 16, 2022 at 1:48 PM Peter Xu <peterx@redhat.com> wrote:
> >
> > On Mon, Aug 15, 2022 at 09:26:37PM +0000, Sean Christopherson wrote:
> > > On Thu, Aug 11, 2022, Peter Xu wrote:
> > > > On Thu, Aug 11, 2022 at 08:12:38PM +0000, Sean Christopherson wrote:
> > > > > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > > > > > index 17252f39bd7c..aeafe0e9cfbf 100644
> > > > > > --- a/arch/x86/kvm/mmu/mmu.c
> > > > > > +++ b/arch/x86/kvm/mmu/mmu.c
> > > > > > @@ -3012,6 +3012,13 @@ static int kvm_handle_bad_page(struct kvm_vcpu *vcpu, gfn_t gfn, kvm_pfn_t pfn)
> > > > > >  static int handle_abnormal_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault,
> > > > > >                                unsigned int access)
> > > > > >  {
> > > > > > +       /* NOTE: not all error pfn is fatal; handle sigpending pfn first */
> > > > > > +       if (unlikely(is_sigpending_pfn(fault->pfn))) {
> > > > >
> > > > > Move this into kvm_handle_bad_page(), then there's no need for a comment to call
> > > > > out that this needs to come before the is_error_pfn() check.  This _is_ a "bad"
> > > > > PFN, it just so happens that userspace might be able to resolve the "bad" PFN.
> > > >
> > > > It's a pity it needs to be in "bad pfn" category since that's the only
> > > > thing we can easily use, but true it is now.
> > >
> > > Would renaming that to kvm_handle_error_pfn() help?  I agree that "bad" is poor
> > > terminology now that it handles a variety of errors, hence the quotes.
> >
> > It could be slightly helpful I think, at least it starts to match with how
> > we name KVM_PFN_ERR_*.  Will squash the renaming into the same patch.
> 
> +1 to kvm_handle_error_pfn(). Weirdly I proposed the same as part of
> another series  yesterday [1]. That being said I'm probably going to
> drop my cleanup patch (specifically patches 7-9) since it conflicts
> with your changes and there is a bug in the last patch.
> 
> [1] https://lore.kernel.org/kvm/20220815230110.2266741-8-dmatlack@google.com/

Thanks for the heads-up.

Please still feel free to keep working on new versions since I'm still not
sure which one will land earlier.  I'll repost very soon on this one (I
just added hugetlb support which I overlooked; it's a touch up in patch 1
only though).  I can always rebase on top too.

-- 
Peter Xu