From: Sean Christopherson <seanjc@google.com>
To: Nikita Kalyazin <kalyazin@amazon.com>
Cc: 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, vkuznets@redhat.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, 11 Feb 2025 10:53:11 -0800 [thread overview]
Message-ID: <Z6ucl7U79RuBsYJt@google.com> (raw)
In-Reply-To: <20241127172654.1024-2-kalyazin@amazon.com>
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
next prev parent reply other threads:[~2025-02-11 18:53 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 [this message]
2025-02-17 13:05 ` Vitaly Kuznetsov
2025-02-18 15:17 ` Sean Christopherson
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=Z6ucl7U79RuBsYJt@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.