Re: [PATCH] drivers/char: mark XHCI DMA buffers reserved in memory map

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.03.2024 14:22, Marek Marczykowski-Górecki wrote:
> On Tue, Mar 12, 2024 at 02:09:14PM +0100, Marek Marczykowski-Górecki wrote:
>> On Tue, Mar 12, 2024 at 01:38:53PM +0100, Jan Beulich wrote:
>>> On 12.03.2024 13:02, Marek Marczykowski-Górecki wrote:
>>>> BTW should e820_change_range_type() return 1 in case of mapping already
>>>> having the right type? Otherwise, if one wants to use
>>>> iommu_add_extra_reserved_device_memory() on already reserved memory, the
>>>> e820_change_range_type() would fail.
>>>
>>> You raised that question on Matrix yesterday, iirc, and I left it
>>> unanswered there because it takes archeology to find the answer (or at
>>> least get closer to one). And, please don't get me wrong, you could as
>>> well do that yourself. (My vague recollection from having dealt with
>>> similar code in Linux is that yes, in the example given the function
>>> ought to indeed have failed back then. Depending on present uses etc
>>> it may well be that we could reconsider, though.)
>>
>> I sure can do some archaeology there, I was just hoping any of you would
>> know the answer already.
> 
> None of the commit messages touching that code give the answer. But
> looking around, most callers of reserve_e820_ram() ignore its return
> value. One exception is reserving memory for kexec. I guess in that case
> it may be intentional to fail if the area is reserved already, as it may
> indicate it cannot be used for kexec. Is that correct?

I suppose so, yes.

> There are also a couple of calls to e820_change_range_type() in tboot
> code where it changes E820_RESERVED to E820_UNUSABLE. There, I guess
> changing e820_change_range_type() behavior would be okay.

Possibly, but please don't put much trust in the tboot code we have.

Jan