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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

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.  While capable of being inlined, mod_l?_entry() are not due to
their size.

~Andrew