On Wed, 19 Feb 2025, Jan Beulich wrote: > On 19.02.2025 16:25, Luca Fancellu wrote: > >> On 19 Feb 2025, at 13:30, Jan Beulich <jbeul...@suse.com> wrote: > >> On 19.02.2025 14:06, Luca Fancellu wrote: > >>>> On 19 Feb 2025, at 12:45, Jan Beulich <jbeul...@suse.com> wrote: > >>>> As per the > >>>> respective revlog entry, this change looks to belong into whatever is > >>>> going to be done to deal with the one Arm use of the macro. Or maybe > >>>> it's unneeded altogether. > >>> > >>> I didn’t understand that you were opposing to protecting > >>> iommu_use_hap_pt() when > >>> !HAS_PASSTHROUGH, I thought you were referring only to the stub in the > >>> #else > >>> branch. > >>> Can I ask why? > >> > >> Sure. And no, I'm not against the extra protection. I'm against unnecessary > >> code churn. That is, any such a re-arrangement wants to have some kind of > >> justification. > > > > ok, yes the justification is that MPU system will be built with > > !HAS_PASSTHROUGH, > > but there is a common function (p2m_set_way_flush) to MMU/MPU subsystem that > > I would like to keep common, to do so I have to hide the macro in this > > particular > > configuration and afterwards I have two choices: > > > > 1) provide a stub implementation on the Arm side > > 2) provide a stub implementation in iommu.h > > > > number 2 felt better because it could be applied on any Xen configuration > > without > > HAS_PASSTHROUGH, even if at the moment there is only MPU. > > > > Number 1 let the possibility for the specific configuration to choose what > > to do in absence > > of HAS_PASSTHROUGH. > > > > Now I would like your view on what would be acceptable here. > > I think I indicated earlier that I'd like the Arm maintainers to voice > their preference. Doing it in iommu.h may be okay, but also may not be. > Yet to decide that very Arm use of the macro needs taking into account, > and I lack context there.
I think that doing it in iommu.h is fine
