Hi Michel,
Am 04.10.19 um 13:36 schrieb Michel Lespinasse:
On Fri, Oct 04, 2019 at 06:54:54AM +0000, Koenig, Christian wrote:
Am 03.10.19 um 22:18 schrieb Davidlohr Bueso:
The amdgpu_vm interval tree really wants [a, b) intervals,
NAK, we explicitly do need an [a, b[ interval here.
Hi Christian,
Just wanted to confirm where you stand on this patch, since I think
you reconsidered your initial position after first looking at 9/11
from this series.
I do not know the amdgpu code well, but I think the changes should be
fine - in struct amdgpu_bo_va_mapping, the "end" field will hold what
was previously stored in the "last" field, plus one. The expectation
is that overflows should not be an issue there, as "end" is explicitly
declared as an uint64, and as the code was previously computing
"last + 1" in many places.
Does that seem workable to you ?
No, we computed last + 1 in a couple of debug places were it doesn't
hurt us and IIRC we currently cheat a bit because we use pfn instead of
addresses on some other places.
But that is only a leftover from radeon and we need to fix that sooner
or later, cause essentially the physical address space of the device is
really full 64bits, e.g. 0x0-0xffffffffffffffff.
So that only fits into a 64bit int when we use half open/closed
intervals, but would wrap around to zero if we use a closed interval.
I initially thought that the set was changing the interval tree into
always using a closed interval, but that seems to have been a
misunderstanding.
Regards,
Christian.
Thanks,
