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? 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. Anyway, since we agree to focus on RAM in this API for now, it shouldn't matter anymore. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab
signature.asc
Description: PGP signature
