kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: James Houghton <jthoughton@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Sean Christopherson <seanjc@google.com>,
	Jonathan Corbet <corbet@lwn.net>, Marc Zyngier <maz@kernel.org>,
	Yan Zhao <yan.y.zhao@intel.com>,
	Nikita Kalyazin <kalyazin@amazon.com>,
	Anish Moorthy <amoorthy@google.com>,
	Peter Gonda <pgonda@google.com>, Peter Xu <peterx@redhat.com>,
	David Matlack <dmatlack@google.com>,
	wei.w.wang@intel.com, kvm@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev
Subject: Re: [PATCH v3 03/15] KVM: arm64: x86: Require "struct kvm_page_fault" for memory fault exits
Date: Wed, 18 Jun 2025 13:00:06 -0700	[thread overview]
Message-ID: <aFMaxi5LDr4HHbMR@linux.dev> (raw)
In-Reply-To: <20250618042424.330664-4-jthoughton@google.com>

On Wed, Jun 18, 2025 at 04:24:12AM +0000, James Houghton wrote:
> +#ifdef CONFIG_KVM_GENERIC_PAGE_FAULT
> +
> +#define KVM_ASSERT_TYPE_IS(type_t, x)					\
> +do {									\
> +	type_t __maybe_unused tmp;					\
> +									\
> +	BUILD_BUG_ON(!__types_ok(tmp, x) || !__typecheck(tmp, x));	\
> +} while (0)
> +
>  static inline void kvm_prepare_memory_fault_exit(struct kvm_vcpu *vcpu,
> -						 gpa_t gpa, gpa_t size,
> -						 bool is_write, bool is_exec,
> -						 bool is_private)
> +						 struct kvm_page_fault *fault)
>  {
> +	KVM_ASSERT_TYPE_IS(gfn_t, fault->gfn);
> +	KVM_ASSERT_TYPE_IS(bool, fault->exec);
> +	KVM_ASSERT_TYPE_IS(bool, fault->write);
> +	KVM_ASSERT_TYPE_IS(bool, fault->is_private);
> +	KVM_ASSERT_TYPE_IS(struct kvm_memory_slot *, fault->slot);
> +
>  	vcpu->run->exit_reason = KVM_EXIT_MEMORY_FAULT;
> -	vcpu->run->memory_fault.gpa = gpa;
> -	vcpu->run->memory_fault.size = size;
> +	vcpu->run->memory_fault.gpa = fault->gfn << PAGE_SHIFT;
> +	vcpu->run->memory_fault.size = PAGE_SIZE;
>  
>  	/* RWX flags are not (yet) defined or communicated to userspace. */
>  	vcpu->run->memory_fault.flags = 0;
> -	if (is_private)
> +	if (fault->is_private)
>  		vcpu->run->memory_fault.flags |= KVM_MEMORY_EXIT_FLAG_PRIVATE;
>  }
> +#endif

This *is not* the right direction of travel for arm64. Stage-2 aborts /
EPT violations / etc. are extremely architecture-specific events.

What I would like to see on arm64 is that for every "KVM_EXIT_MEMORY_FAULT"
we provide as much syndrome information as possible. That could imply
some combination of a sanitised view of ESR_EL2 and, where it is
unambiguous, common fault flags that have shared definitions with x86.
This could incur some minor code duplication, but even then we can share
helpers for the software bits (like userfault).

FEAT_MTE_PERM is a very good example for this. There exists a "Tag"
permission at stage-2 which is unrelated to any of the 'normal'
read/write permissions. There's also the MostlyReadOnly permission from
FEAT_THE which grants write permission to a specific set of instructions.

I don't want to paper over these nuances and will happily maintain an
arm64-specific flavor of "kvm_prepare_memory_fault_exit()"/

Thanks,
Oliver

  reply	other threads:[~2025-06-18 20:00 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-18  4:24 [PATCH v3 00/15] KVM: Introduce KVM Userfault James Houghton
2025-06-18  4:24 ` [PATCH v3 01/15] KVM: x86/mmu: Move "struct kvm_page_fault" definition to asm/kvm_host.h James Houghton
2025-06-18  4:24 ` [PATCH v3 02/15] KVM: arm64: Add "struct kvm_page_fault" to gather common fault variables James Houghton
2025-06-18 19:26   ` Oliver Upton
2025-06-18 21:17     ` Sean Christopherson
2025-06-18  4:24 ` [PATCH v3 03/15] KVM: arm64: x86: Require "struct kvm_page_fault" for memory fault exits James Houghton
2025-06-18 20:00   ` Oliver Upton [this message]
2025-06-18 20:47     ` Sean Christopherson
2025-06-18 23:14       ` Oliver Upton
2025-06-19  1:22         ` Sean Christopherson
2025-06-18  4:24 ` [PATCH v3 04/15] KVM: Add common infrastructure for KVM Userfaults James Houghton
2025-06-18 19:40   ` Oliver Upton
2025-06-18 20:33     ` Sean Christopherson
2025-06-18 20:41       ` James Houghton
2025-06-18 22:43       ` Oliver Upton
2025-06-19  1:27         ` Sean Christopherson
2025-06-18 20:38     ` James Houghton
2025-06-18  4:24 ` [PATCH v3 05/15] KVM: x86: Add support for KVM userfault exits James Houghton
2025-07-30 21:11   ` James Houghton
2025-06-18  4:24 ` [PATCH v3 06/15] KVM: arm64: " James Houghton
2025-06-18  4:24 ` [PATCH v3 07/15] KVM: Enable and advertise " James Houghton
2025-06-18  4:24 ` [PATCH v3 08/15] KVM: selftests: Fix vm_mem_region_set_flags docstring James Houghton
2025-06-18  4:24 ` [PATCH v3 09/15] KVM: selftests: Fix prefault_mem logic James Houghton
2025-06-18  4:24 ` [PATCH v3 10/15] KVM: selftests: Add va_start/end into uffd_desc James Houghton
2025-06-18  4:24 ` [PATCH v3 11/15] KVM: selftests: Add KVM Userfault mode to demand_paging_test James Houghton
2025-06-18  4:24 ` [PATCH v3 12/15] KVM: selftests: Inform set_memory_region_test of KVM_MEM_USERFAULT James Houghton
2025-06-18  4:24 ` [PATCH v3 13/15] KVM: selftests: Add KVM_MEM_USERFAULT + guest_memfd toggle tests James Houghton
2025-06-18  4:24 ` [PATCH v3 14/15] KVM: Documentation: Fix section number for KVM_CAP_ARM_WRITABLE_IMP_ID_REGS James Houghton
2025-06-18  4:24 ` [PATCH v3 15/15] KVM: Documentation: Add KVM_CAP_USERFAULT and KVM_MEM_USERFAULT details James Houghton
2025-06-18 23:24 ` [PATCH v3 00/15] KVM: Introduce KVM Userfault Oliver Upton
2025-09-04 16:43 ` Nikita Kalyazin
2025-09-04 18:45   ` James Houghton
2025-09-05 12:27     ` 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=aFMaxi5LDr4HHbMR@linux.dev \
    --to=oliver.upton@linux.dev \
    --cc=amoorthy@google.com \
    --cc=corbet@lwn.net \
    --cc=dmatlack@google.com \
    --cc=jthoughton@google.com \
    --cc=kalyazin@amazon.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=pgonda@google.com \
    --cc=seanjc@google.com \
    --cc=wei.w.wang@intel.com \
    --cc=yan.y.zhao@intel.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).