Re: [PATCH v2 3/7] x86: extend update_intpte() to support atomic get-and-update

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.09.2026 21:37, Kevin Lampis wrote:
>> This seems unwise.  I think you want a return 0 in the
>> paging_write_guest_entry() case because returning the input cannot
>> possibly lead to anything good.
> 
> This would make the calling code in mod_l1_entry() more complicated.
> 
> At the moment it shakes out like this
>     static int mod_l1_entry(l1_pgentry_t *pl1e,
>                             ...,
>                             l1_pgentry_t *ol1e_out)
>     {
>         l1_pgentry_t ol1e = l1e_read(pl1e);
>         ...
>         ol1e = UPDATE_ENTRY(l1, pl1e, ol1e, ...);
>         ...
>         put_page_from_l1e(ol1e, pt_dom);
>         ...
>         if ( ol1e_out )
>             *ol1e_out = ol1e;
>     }
> 
> But if UPDATE_ENTRY() sometimes returns 0 depending on what internal path it
> takes then we'll need two local ol1e variables, one that is always valid to
> give to put_page_from_l1e() and a different one to maybe assign to *ol1e_out.
> 
> When you say "returning the input cannot possibly lead to anything good", the
> current version of this patch series actually depends on it.

Does it? I've peeked ahead only to the next patch so far, but aren't you
going to use the new PTE_UPDATE_SWAP flag? And isn't ol1e_out being non-
NULL tied to that new flag being set? Mixing both is what I think Andrew
in concerned about. The "flag set, pointer non-NULL" case wouldn't hit
the "return 0" path, aiui.

Jan