Re: [PATCH v3 4/8] pdx: allow per-arch optimization of PDX conversion helpers

[Jan Beulich <jbeulich@xxxxxxxx>]

On 24.07.2025 13:04, Roger Pau Monne wrote:
> There are four performance critical PDX conversion helpers that do the PFN
> to/from PDX and the physical addresses to/from directmap offsets
> translations.
> 
> In the absence of an active PDX compression, those functions would still do
> the calculations needed, just to return the same input value as no
> translation is in place and hence PFN and PDX spaces are identity mapped.
> 
> To reduce the overhead of having to do the pointless calculations allow
> architectures to implement the translation helpers in a per-arch header.
> Rename the existing conversion functions to add a trailing _xlate suffix,
> so that the per-arch headers can define the non suffixed versions.
> 
> Currently only x86 implements meaningful custom handlers to short circuit
> the translation when not active, using asm goto.  Other architectures use a
> generic header that maps the non-xlate to the xlate variants to keep the
> previous behavior.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

> --- /dev/null
> +++ b/xen/arch/x86/include/asm/pdx.h
> @@ -0,0 +1,75 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef X86_PDX_H
> +#define X86_PDX_H
> +
> +#ifndef CONFIG_PDX_NONE
> +
> +#include <asm/alternative.h>
> +
> +/*
> + * Introduce a macro to avoid repeating the same asm goto block in each 
> helper.
> + * Note the macro is strictly tied to the code in the helpers.
> + */
> +#define PDX_ASM_GOTO(label)                         \
> +    asm_inline goto (                               \
> +        ALTERNATIVE(                                \
> +            "",                                     \
> +            "jmp %l0",                              \
> +            ALT_NOT(X86_FEATURE_PDX_COMPRESSION))   \
> +        : : : : label )

Considering the uses of the macro, it seems likely that in some of the cases the
label will be within reach of a short JMP (opcode 0xEB), while the assembler 
will
be unable to encode it like that (for living in a separate section, far off from
the place the code will be copied to). That's likely okay for now, but we may
want to eliminate this minor ineffeciency later on.

Jan