Hi Stefano,

> On 4 Mar 2025, at 19:22, Stefano Stabellini <sstabell...@kernel.org> wrote:
> 
> 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

Thanks for sharing your view, Jan if you are ok with that, I’ll respin this 
patch with the stub implementation
in iommu.h.

Cheers,
Luca

Reply via email to