Re: [PATCH] x86/pv: drop the old GDT frames only after their translations are flushed

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.10.2026 12:37, George Dunlap wrote:
> pv_set_gdt() tears down the old GDT before installing the new one, and
> the teardown, pv_destroy_gdt(), puts each old frame's reference before
> it rewrites the slot's entry; the flush of the slot's translation is
> left to the hypercall wrappers, after pv_set_gdt() returns.  If a put
> drops the last reference, the frame can be freed and reused while this
> pCPU's TLB still translates the slot to it.
> 
> This is safe today only by inspection.  The only consumers of a vCPU's
> GDT slots are descriptor fetches by that vCPU and Xen's trap-handling
> paths on its behalf, none of which run between the put and the flush;
> and every other caller of pv_destroy_gdt() acts on a vCPU that no pCPU
> has loaded, which holds no translations at all.  pv_destroy_ldt() is
> in the same position: it unmaps and puts, and returns whether its
> callers need to flush, so there too the put precedes the flush, and
> the arrangement holds only because nothing fetches through the slots
> in between.
> 
> Restructure pv_set_gdt() so that the flush sits between the two: take
> the references on the new frames, install them (and the zero page over
> the unused slots) over the old mappings, flush if the vCPU is the
> current one, and only then put the old frames.  The flush moves out of
> do_set_gdt() and compat_set_gdt() to sit next to what it protects.
> pv_destroy_gdt() is then only reached for vCPUs that are not loaded
> anywhere, so it asserts that directly (!vcpu_cpu_dirty()), which also
> covers the lazy switched-out state that a plain v != current test
> would let through.  Like pv_destroy_ldt(), it does no flush of its own
> and is safe because the mappings it tears down are not live; it
> unmaps before it puts all the same, so that a flush has its natural
> place should one ever become necessary there.
> 
> No change to what guests observe: a slot always holds the old frame,
> the new frame, or the zero page; there is never an unmapped slot.
> 
> Assisted-by: Claude Code:claude-fable-5
> Signed-off-by: George Dunlap <gwd@xxxxxxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>