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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan