Re: [PATCH v2 03/14] x86/pv: use populate_perdomain_mapping() to map the Xen GDT

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.09.2026 11:43, George Dunlap wrote:
> From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> 
> Currently, update_xen_slot_in_full_gdt() uses the stashed direct-map
> pointer in d->arch.pv.gdt_ldt_l1tab to update the incoming vcpu's
> page tables with Xen's GDT, by writing a stashed per-cpu copy of a
> pre-baked L1 entry (either 64-bit or compat version).
> 
> Switch this to using populate_perdomain_mapping(), which doesn't rely
> on the stashed address of the l1 page in the direct map.  Rather than
> also stashing a pre-baked value for the payload, compute the mfn from
> the per-cpu GDT pointer at use: the conversion is a handful of cycles
> on a path costing thousands, and computing at use removes the
> parallel {,compat_}gdt_l1e bookkeeping along with its boot-ordering
> constraint (the cached value could only be generated after Xen's
> physical relocation, and had to be in place before the first context
> switch; a use-time lookup is correct by construction).  The flags on
> the final mapping are identical.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8
> Signed-off-by: George Dunlap <gwd@xxxxxxxxxxxxxx>
> ---
> Changes in v2:
> - Drop the {,compat_}gdt_mfn caching entirely (suggested by Andrew
>    Cooper): compute virt_to_mfn() from the per-cpu GDT pointer at use.
>    The PDX lookup behind it measures ~5-10 cycles warm against a
>    ~1,500-cycle context switch, and this removes the double
>    bookkeeping and the after-relocation caching constraint.  The
>    cached-MFN assertion goes with the cache: a use-time computation
>    from a live pointer needs no staleness check.

This looks to contradict what 564d261687c0 ("x86/ctxt-switch: Document
and improve GDT handling") used as justification to put in place the
caching. Also Cc-ing Jürgen, who also was involved there, for possible
further insight.

Functionally the change looks okay to me, but the above will need
sorting, at the very least by specifically discussing why effectively
undoing that earlier change is okay.

Jan