On 2018-03-13 10:28 AM, Jerome Glisse wrote:
> On Mon, Mar 12, 2018 at 02:28:42PM -0400, Felix Kuehling wrote:
>> On 2018-03-10 10:01 AM, Christian König wrote:
>>>> To accomodate those we need to
>>>> create a "hole" inside the process address space. Thi
On 2018-03-10 10:01 AM, Christian König wrote:
>> To accomodate those we need to
>> create a "hole" inside the process address space. This patchset have
>> a hack for that (patch 13 HACK FOR HMM AREA), it reserves a range of
>> device file offset so that process can mmap this range with PROT_NONE
t sweeps over its pfns array a couple of times anyhow.
>
> Signed-off-by: Jason Gunthorpe
> Signed-off-by: Christoph Hellwig
Hi Jason,
I pointed out a typo in the documentation inline. Other than that, the
series is
Acked-by: Felix Kuehling
I'll try to build it and run so
Am 2021-04-06 um 9:04 a.m. schrieb Christian König:
> Am 06.04.21 um 14:52 schrieb Thomas Zimmermann:
>> Hi
>>
>> Am 06.04.21 um 14:42 schrieb Christian König:
>>> Hi Thomas,
>>>
>>> Am 06.04.21 um 13:55 schrieb Thomas Zimmermann:
Hi
Am 06.04.21 um 12:56 schrieb Christian König:
Am 2021-04-06 um 6:38 a.m. schrieb Thomas Zimmermann:
> Hi
>
> Am 06.04.21 um 11:35 schrieb Christian König:
>> Am 06.04.21 um 11:08 schrieb Thomas Zimmermann:
>>> Moving the driver-specific mmap code into a GEM object function allows
>>> for using DRM helpers for various mmap callbacks.
>>>
>>>
On 2021-04-07 7:25 a.m., Christian König wrote:
+ /*
+ * Don't verify access for KFD BOs. They don't have a GEM
+ * object associated with them.
+ */
+ if (bo->kfd_bo)
+ goto out;
Who does the access verification now?
This is somewhat confusing.
I took this check
On 2021-04-07 3:34 p.m., Felix Kuehling wrote:
On 2021-04-07 7:25 a.m., Christian König wrote:
+ /*
+ * Don't verify access for KFD BOs. They don't have a GEM
+ * object associated with them.
+ */
+ if (bo->kfd_bo)
+ goto out;
Who does the access verification
Am 2021-04-20 um 4:51 a.m. schrieb Daniel Vetter:
>>> Whole series is Reviewed-by: Christian König
>> Thanks a lot. If I'm not mistaken, the patches at [1] need to go in first.
>> So it could take a a bit until this lands.
>>
>> Otherwise, this series could go through the same tree as [1] if
Am 2021-04-14 um 3:44 a.m. schrieb Thomas Zimmermann:
> Hi
>
> Am 07.04.21 um 21:49 schrieb Felix Kuehling:
>> On 2021-04-07 3:34 p.m., Felix Kuehling wrote:
>>> On 2021-04-07 7:25 a.m., Christian König wrote:
>>>>>>>> + /*
>>>>>
t; Signed-off-by: Alistair Popple
It makes sense to me. Do you have any empirical data on how much more
likely migrations are going to fail with this change due to contested
page locks?
Either way, the patch is
Acked-by: Felix Kuehling
> ---
> Documentation/vm/hmm.rst | 2 +
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
Signed-off-by: Alex Deucher
Furthermore, I guess we are assuming that nobody is using the GPU when
the module is unloaded. As long as any processes have /dev/kfd open, you
won't be able to unload the module (except by force-unload).
cks, so we won't have to deal with it in all the migration code.
Regards,
Felix
Signed-off-by: Alistair Popple
Cc: Jason Gunthorpe
Cc: John Hubbard
Cc: Ralph Campbell
Cc: Michael Ellerman
Cc: Felix Kuehling
Cc: Lyude Paul
---
arch/powerpc/kvm/book3s_hv_uvmem.c |
l code can then safely use kernel functions such as
get_page_unless_zero().
Signed-off-by: Alistair Popple
Acked-by: Felix Kuehling
Cc: Jason Gunthorpe
Cc: Michael Ellerman
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: Christian König
Cc: Ben Skeggs
Cc: Lyude Paul
Cc: Ralph Campbell
Cc: Alex Sierra
Am 2022-10-02 um 20:53 schrieb Alistair Popple:
Felix Kuehling writes:
On 2022-09-28 08:01, Alistair Popple wrote:
When the CPU tries to access a device private page the migrate_to_ram()
callback associated with the pgmap for the page is called. However no
reference is taken on the faulting
14 matches
Mail list logo
