Re: [PATCH v5 4/6] x86: extend do_mmu_update() to support returning the old PTE value

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.11.2026 17:57, Andrew Cooper wrote:
> On 12/11/2026 2:06 pm, Jan Beulich wrote:
>> On 12.11.2026 11:00, Kevin Lampis wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -4123,6 +4123,7 @@ long do_mmu_update(
>>>          case MMU_NORMAL_PT_UPDATE:
>>>          case MMU_PT_UPDATE_PRESERVE_AD:
>>>          case MMU_PT_UPDATE_NO_TRANSLATE:
>>> +        case MMU_PT_UPDATE_SWAP:
>>>          {
>>>              p2m_type_t p2mt;
>>>  
>>> @@ -4184,37 +4185,79 @@ long do_mmu_update(
>>>                       update_flags = PTE_UPDATE_PRESERVE_AD;
>>>                  else if ( cmd == MMU_PT_UPDATE_NO_TRANSLATE )
>>>                       update_flags = PTE_UPDATE_NO_TRANSLATE;
>>> +                else if ( cmd == MMU_PT_UPDATE_SWAP )
>>> +                     update_flags = PTE_UPDATE_SWAP;
>>>  
>>>                  switch ( page->u.inuse.type_info & PGT_type_mask )
>>>                  {
>>>                  case PGT_l1_page_table:
>>> +                {
>>> +                    l1_pgentry_t ol1e = {};
>>>                      rc = mod_l1_entry(va, l1e_from_intpte(req.val), mfn,
>>> -                                      update_flags, v, pg_owner, NULL);
>>> -                    break;
>>> +                                      update_flags, v, pg_owner, &ol1e);
>>>  
>>> +                    if ( !rc && cmd == MMU_PT_UPDATE_SWAP )
>>> +                    {
>>> +                        req.val = ol1e.l1;
>> If you didn't open-code l1e_get_intpte() here, it would become more obvious
>> that the INTPTE -> L<n>E done in mod_l<n>_entry() is simply being reversed
>> here. If ol1e was of type intpte_t, doing the update in update_intpte() (and
>> not UPDATE_ENTRY()) would become feasible. Since intpte_t is a mere alias of
>> uint64_t, passing &req.val into mod_l<n>_entry() directly would then also
>> become possible. Less redundancy would be the result.
> 
> Perhaps, but then it would be odd to have mod_l1_entry() require nl1e in
> a typesafe way while passing back ol1e as type unsafe.

If the sole purpose of those parameters is to obtain a type-unsafe intpte_t
(for use here), I'm not convinced this oddity would be overly problematic.

> And there's still the problem of reading ol1e.  We could change the
> indirection of ol?e, but that's invasive both at the source and binary
> level.

I said "passing &req.val" though - no change in indirection.

>  While capable of being inlined, mod_l?_entry() are not due to
> their size.

Yes for mod_l1_entry(), but not for the other three afaics (debug build
with gcc16).

Jan