linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Nikita Kalyazin <kalyazin@amazon.com>,
	pbonzini@redhat.com, corbet@lwn.net,  tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de,  dave.hansen@linux.intel.com,
	x86@kernel.org, hpa@zytor.com,  xiaoyao.li@intel.com,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	 linux-doc@vger.kernel.org, roypat@amazon.co.uk,
	xmarcalx@amazon.com
Subject: Re: [PATCH 1/2] KVM: x86: async_pf: remove support for KVM_ASYNC_PF_SEND_ALWAYS
Date: Tue, 18 Feb 2025 07:17:17 -0800	[thread overview]
Message-ID: <Z7SkfSRsE5hcsrRe@google.com> (raw)
In-Reply-To: <87frkcrab8.fsf@redhat.com>

On Mon, Feb 17, 2025, Vitaly Kuznetsov wrote:
> Sean Christopherson <seanjc@google.com> writes:
> 
> > On Wed, Nov 27, 2024, Nikita Kalyazin wrote:
> >> 3a7c8fafd1b42adea229fd204132f6a2fb3cd2d9 ("x86/kvm: Restrict
> >> ASYNC_PF to user space") stopped setting KVM_ASYNC_PF_SEND_ALWAYS in
> >> Linux guests.  While the flag can still be used by legacy guests, the
> >> mechanism is best effort so KVM is not obliged to use it.
> >
> > What's the actual motivation to remove it from KVM?  I agreed KVM isn't required
> > to honor KVM_ASYNC_PF_SEND_ALWAYS from a guest/host ABI perspective, but that
> > doesn't mean that dropping a feature has no impact.  E.g. it's entirely possible
> > removing this support could negatively affect a workload running on an old kernel.
> >
> > Looking back at the discussion[*] where Vitaly made this suggestion, I don't see
> > anything that justifies dropping this code.  It costs KVM practically nothing to
> > maintain this code.
> >
> > [*] https://lore.kernel.org/all/20241118130403.23184-1-kalyazin@amazon.com
> >
> 
> How old is old? :-)
> 
> Linux stopped using KVM_ASYNC_PF_SEND_ALWAYS in v5.8: 

5.8 is practically a baby.  Maybe a toddler :-)

> commit 3a7c8fafd1b42adea229fd204132f6a2fb3cd2d9
> Author: Thomas Gleixner <tglx@linutronix.de>
> Date:   Fri Apr 24 09:57:56 2020 +0200
> 
>     x86/kvm: Restrict ASYNC_PF to user space
> 
> and I was under the impression other OSes never used KVM asynchronous
> page-fault in the first place (not sure about *BSDs though but certainly
> not Windows). As Nikita's motivation for the patch was "to avoid the
> overhead ... in case of kernel-originated faults" I suggested we start
> by simplifyign the code to not care about 'send_user_only' at all. 

In practice, I don't think it's a meaningful simplification.  There are other
scenarios where KVM shouldn't inject an async #PF, so kvm_can_deliver_async_pf()
itself isn't going anywhere.

AFAICT, what Nikita actually wants is a way to disable host-side async #PF, e.g.

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index f97d4d435e7f..d461e1b5489c 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -13411,7 +13411,8 @@ bool kvm_can_do_async_pf(struct kvm_vcpu *vcpu)
                     kvm_is_exception_pending(vcpu)))
                return false;
 
-       if (kvm_hlt_in_guest(vcpu->kvm) && !kvm_can_deliver_async_pf(vcpu))
+       if ((kvm_hlt_in_guest(vcpu->kvm) || kvm_only_pv_async_pf(vcpu->kvm)) &&
+           !kvm_can_deliver_async_pf(vcpu))
                return false;
 
        /*

> We can keep the code around, I guess, but with no plans to re-introduce
> KVM_ASYNC_PF_SEND_ALWAYS usage to Linux I still believe it would be good
> to set a deprecation date.

  reply	other threads:[~2025-02-18 15:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-27 17:26 [PATCH 0/2] KVM_ASYNC_PF_SEND_ALWAYS Nikita Kalyazin
2024-11-27 17:26 ` [PATCH 1/2] KVM: x86: async_pf: remove support for KVM_ASYNC_PF_SEND_ALWAYS Nikita Kalyazin
2025-02-11 18:53   ` Sean Christopherson
2025-02-17 13:05     ` Vitaly Kuznetsov
2025-02-18 15:17       ` Sean Christopherson [this message]
2025-02-18 17:07         ` Nikita Kalyazin
2024-11-27 17:26 ` [PATCH 2/2] KVM: x86: async_pf: determine x86 user as cpl == 3 Nikita Kalyazin
2025-02-11 19:12   ` Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z7SkfSRsE5hcsrRe@google.com \
    --to=seanjc@google.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=kalyazin@amazon.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=roypat@amazon.co.uk \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=x86@kernel.org \
    --cc=xiaoyao.li@intel.com \
    --cc=xmarcalx@amazon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).