Re: [RFC PATCH 2/2] vtd: Replace macros with bitfield

[Teddy Astie <teddy.astie@xxxxxxxxxx>]

Le 20/04/2026 à 15:54, Jan Beulich a écrit :
> On 10.04.2026 12:09, Teddy Astie wrote:
>> Replace macros with bitfield to allow simplyfing the code and be
>> less error prone when manipulating PTEs.
>>
>> It also has the effect of directly exposing the mfn in the pte struct
>> instead of derivating it from the raw pte value using dma_pte_addr().
>>
>> Signed-off-by: Teddy Astie <teddy.astie@xxxxxxxxxx>
>> ---
>> It allows nicer constructs like
>>
>>    new.snp = iommu_snoop;
>>
>> instead of
>>
>>    if ( iommu_snoop )
>>      dma_set_pte_snp(new);
>>
>> A lot of simplifications could be done afterward when switching the
>> logic from maddrs to mfns i.e remove many maddr-mfn conversions.
> 
> There's no real open question here, so it's not quite clear why this is
> marked RFC. We did do the same on the AMD side a while back, at least
> partly (I don't think we got all of it converted yet), so doing the
> conversion here surely is a good thing. The slightly larger ...
> 
>> bloat-o-meter (along with the previous change)
>>
>> add/remove: 0/0 grow/shrink: 7/3 up/down: 227/-45 (182)
>> Function                                     old     new   delta
>> addr_to_dma_page_maddr                       949    1058    +109
>> vtd_dump_page_table_level                    197     233     +36
>> fill_qpt                                    1151    1178     +27
>> print_vtd_entries                            486     504     +18
>> domain_context_mapping_one                  2098    2114     +16
>> intel_iommu_map_page                         909     921     +12
>> intel_iommu_unmap_page                       731     740      +9
>> intel_iommu_lookup_page                      185     176      -9
>> queue_free_pt                                442     425     -17
>> vtd_dump_page_table_level.cold                86      67     -19
>> Total: Before=18446744073715636162, After=18446744073715636344, chg +0.00%
> 
> ... code size shouldn't be much of a concern, albeit you may want to at
> least mention the (presumed) reason for some of the bigger increases,
> after comparing the generated code.
> 
> (As an aside, the two values after Total: look entirely bogus.)
> 
>> I guess using mfns 'everywhere' would improve the bloat-o-meter picture.
> 
> It's not quite clear to me what you mean here.
> 

There are many mfn<->maddr conversions done at various places which can 
be eliminated. I guess some of the "bloat" is coming from there.

I may try in another patch to adjust some of the types to make that better.

> Jan
> 



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech