Re: [PATCH 4/4] x86: add new pte_get_and_clear hypercall

Teddy Astie <[email protected]> Tue, 4 Aug 2026 12:30:37 +0200
Newsgroups	org.xenproject.lists.xen-devel
Message-ID	<1785839438.8631fc262581453bbf619ec5b2062170.19fcc534b55000e099@vates.tech>
Le 27/07/2026 à 17:07, Kevin Lampis a écrit :
> This new hypercall uses the same interface as the mmu_update hypercall except
> the old PTE value is returned in the mmu_update_t->val field.
> 
> The purpose of this new hypercall is to improve performance over the current
> trap and emulate behavior. Only l1 PTEs are supported because they have the
> biggest performance impact.
> 
> Signed-off-by: Kevin Lampis <[email protected]>
> ---
>   xen/arch/x86/mm.c            | 24 +++++++++++++++++-------
>   xen/include/hypercall-defs.c |  2 ++
>   xen/include/public/xen.h     |  1 +
>   3 files changed, 20 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 278b992aca5c..e5fdfc66081a 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -3993,6 +3993,7 @@ static long __do_mmu_update(
>       unsigned int count,

...

>   #endif /* CONFIG_PV */
> diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c
> index a625d634b694..0552e93ab560 100644
> --- a/xen/include/hypercall-defs.c
> +++ b/xen/include/hypercall-defs.c
> @@ -174,6 +174,7 @@ multicall(multicall_entry_t *call_list, unsigned long nr_calls)
>   #ifdef CONFIG_PV
>   mmuext_op(mmuext_op_t *uops, unsigned int count, unsigned int *pdone, unsigned int foreigndom)
>   mmu_update(mmu_update_t *ureqs, unsigned int count, unsigned int *pdone, unsigned int foreigndom)
> +pte_get_and_clear(mmu_update_t *ureqs, unsigned int count, unsigned int *pdone, unsigned int foreigndom)
>   stack_switch(unsigned long ss, unsigned long esp)
>   fpu_taskswitch(int set)
>   set_debugreg(int reg, unsigned long value)
> @@ -232,6 +233,7 @@ caller: arm
>   table:                             pv32     pv64     hvm32    hvm64    arm
>   set_trap_table                     compat   do       -        -        -
>   mmu_update                         do:1     do:1     -        -        -
> +pte_get_and_clear                  do:1     do:1     -        -        -
>   set_gdt                            compat   do       -        -        -
>   stack_switch                       do:2     do:2     -        -        -
>   set_callbacks                      compat   do       -        -        -
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 2149b8dd3808..9e2ba0107d3b 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -118,6 +118,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>   #define __HYPERVISOR_xenpmu_op            40
>   #define __HYPERVISOR_dm_op                41
>   #define __HYPERVISOR_hypfs_op             42
> +#define __HYPERVISOR_pte_get_and_clear    43
>   

I'm not sure __HYPERVISOR_pte_get_and_clear is a great name, as I 
understand it, it's more that it's doing (more general) CMPXCHG 
operation and returning the old value than strictly doing a 
get_and_clear one (which is the main intent for Linux).

I also think we can find a way to expand HYPERVISOR_mmu_update instead 
of introducing a new hypercall.

HYPERVISOR_mmu_update actually has a undocumented "actually reserved 
bit" (at least, for PV32-pae and PV64 guests) which currently must be 
zero (otherwise, hypercall fails); but we can repurpose it to expand 
available command count to add "cmpxchg semantics" variants. That would 
greatly simplify the implementation as we won't have to introduce a new 
separate hypercall just for this.
(I will send a patch regarding this in particular)

---

Aside that, new features wants to be enumerated so that the kernel knows 
that it's supported before trying to use it. We can expand features.h 
with a new flag for this.

>   /* Architecture-specific hypercall definitions. */
>   #define __HYPERVISOR_arch_0               48

Teddy
OpenPGP_0x660FA9D102CBCFD0.asc (application/pgp-keys, 2.4 KB)
OpenPGP_signature.asc (application/pgp-signature, 665 B)