From: Sean Christopherson <seanjc@google.com>
To: Rick P Edgecombe <rick.p.edgecombe@intel.com>
Cc: "x86@kernel.org" <x86@kernel.org>,
"zhangjiaji1@huawei.com" <zhangjiaji1@huawei.com>,
"kas@kernel.org" <kas@kernel.org>,
Xiaoyao Li <xiaoyao.li@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
"binbin.wu@linux.intel.com" <binbin.wu@linux.intel.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"michael.roth@amd.com" <michael.roth@amd.com>
Subject: Re: [PATCH 14/14] KVM: x86: Add helpers to prepare kvm_run for userspace MMIO exit
Date: Tue, 3 Mar 2026 11:44:12 -0800 [thread overview]
Message-ID: <aac6DGISvMX4krhb@google.com> (raw)
In-Reply-To: <4574be9a29d75d565e553579ef6ce915ef33b19b.camel@intel.com>
On Tue, Mar 03, 2026, Rick P Edgecombe wrote:
> On Mon, 2026-03-02 at 18:24 -0800, Sean Christopherson wrote:
> > Ooh, better idea. Since TDX is the only direct user of
> > __kvm_prepare_emulated_mmio_exit() and it only supports lenths of 1, 2, 4, and 8,
> > kvm_prepare_emulated_mmio_exit() is the only path that actually needs to cap the
> > length. Then the inner helper can assert a valid length. Doesn't change anything
> > in practice, but I like the idea of making the caller be aware of the limitation
> > (even if that caller is itself a helper).
>
> Seems ok and an improvement over the patch. But looking at the other callers,
> there is quite a bit of min(8u, len) logic spread around. Might be worth a wider
> cleanup someday.
LOL, "might". :-)
Definitely a project for the future though, especially given how subtle and brittle
this all is.
next prev parent reply other threads:[~2026-03-03 19:44 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-25 1:20 [PATCH 00/14] KVM: x86: Emulator MMIO fix and cleanups Sean Christopherson
2026-02-25 1:20 ` [PATCH 01/14] KVM: x86: Use scratch field in MMIO fragment to hold small write values Sean Christopherson
2026-02-25 1:20 ` [PATCH 02/14] KVM: x86: Open code handling of completed MMIO reads in emulator_read_write() Sean Christopherson
2026-02-25 1:20 ` [PATCH 03/14] KVM: x86: Trace unsatisfied MMIO reads on a per-page basis Sean Christopherson
2026-02-25 1:20 ` [PATCH 04/14] KVM: x86: Use local MMIO fragment variable to clean up emulator_read_write() Sean Christopherson
2026-02-25 1:20 ` [PATCH 05/14] KVM: x86: Open code read vs. write userspace MMIO exits in emulator_read_write() Sean Christopherson
2026-02-25 1:20 ` [PATCH 06/14] KVM: x86: Move MMIO write tracing into vcpu_mmio_write() Sean Christopherson
2026-02-25 1:20 ` [PATCH 07/14] KVM: x86: Harden SEV-ES MMIO against on-stack use-after-free Sean Christopherson
2026-02-25 1:20 ` [PATCH 08/14] KVM: x86: Dedup kvm_sev_es_mmio_{read,write}() Sean Christopherson
2026-02-25 1:20 ` [PATCH 09/14] KVM: x86: Consolidate SEV-ES MMIO emulation into a single public API Sean Christopherson
2026-02-25 1:20 ` [PATCH 10/14] KVM: x86: Bury emulator read/write ops in emulator_{read,write}_emulated() Sean Christopherson
2026-02-25 1:20 ` [PATCH 11/14] KVM: x86: Fold emulator_write_phys() into write_emulate() Sean Christopherson
2026-02-25 1:20 ` [PATCH 12/14] KVM: x86: Rename .read_write_emulate() to .read_write_guest() Sean Christopherson
2026-02-25 1:20 ` [PATCH 13/14] KVM: x86: Don't panic the kernel if completing userspace I/O / MMIO goes sideways Sean Christopherson
2026-02-25 1:20 ` [PATCH 14/14] KVM: x86: Add helpers to prepare kvm_run for userspace MMIO exit Sean Christopherson
2026-02-25 17:32 ` Edgecombe, Rick P
2026-02-25 19:22 ` Sean Christopherson
2026-03-03 2:24 ` Sean Christopherson
2026-03-03 19:21 ` Edgecombe, Rick P
2026-03-03 19:44 ` Sean Christopherson [this message]
2026-03-03 19:51 ` Edgecombe, Rick P
2026-02-25 17:32 ` [PATCH 00/14] KVM: x86: Emulator MMIO fix and cleanups Edgecombe, Rick P
2026-02-25 20:19 ` Tom Lendacky
2026-02-27 20:19 ` Tom Lendacky
2026-03-05 17:07 ` 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=aac6DGISvMX4krhb@google.com \
--to=seanjc@google.com \
--cc=binbin.wu@linux.intel.com \
--cc=kas@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
--cc=xiaoyao.li@intel.com \
--cc=zhangjiaji1@huawei.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.