[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v2 14/15] drm/amdgpu: Use mmu_range_notifier instead of hmm_mirror
- To: "Yang, Philip" <Philip.Yang@xxxxxxx>
- From: Jason Gunthorpe <jgg@xxxxxxxxxxxx>
- Date: Fri, 1 Nov 2019 19:51:28 +0000
- Accept-language: en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mellanox.com; dmarc=pass action=none header.from=mellanox.com; dkim=pass header.d=mellanox.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NWwZ2XtdGwxXjxwE/hReH72BscduCJm9z5Bp/6u1AC4=; b=V+IDmekWZuGV6Z12P6wVY14yTl1Gaq4d8xC4pWWUCquw62SOv9HqPAV8MrejbAxGwLgwvvUqA5XTSUwz6P/23Om7e+gN9PtrErcuvHQ/bOKmQKUZAF2Iovbfav4EhvlyOKRYqBOW+t0yTuAcidsJiFzz/E+mUKIXIa79mK9PcHCcLRf6W8oqVPK1vFepKcCqpbBrFv5D+BhyyXzOmAHGsMrdseayVM86PixYoWq5b93jWooUHfWYRGBSnTgwR88sEJNO6w5JtHjix42cUHU+MQ80jqy6GaiDGDV+P93FLCbN+7zgwllYCQGEZCB2J0s9KyT2TOXHShl5Sy/ODmM4OA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ldRQgE1Rj7/zZaUqx7Vnh1bdZUlsajSRmfBrrZfdb9ufwcBY5lmjgglWbVMczagp71+yIzgs+5JaCQk4+SYSGOz14LKgAc3Rm2bJjVxRfpNpv5HzWr9nuoXtLWYjA9x3sERuT1b8KvXs4dGuc/w3UjokFtbNUd+3gz9jnqeDKQY35VLtVJxIW+9Jk/tpTpC2B31//ibANRhrUDaS7qtHnM8k7rDIOwVsKbe1pS6qBSaShm+D2wHbrjztsB75i8ucq8SC0IzOiI8rG17DBjoj7H4eGkpg+JOHx3ztbSSlfpIewGW3l4gWBWXKL+TEux1CiGvpbsuuXxeqwM6movRemw==
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=jgg@xxxxxxxxxxxx;
- Cc: "nouveau@xxxxxxxxxxxxxxxxxxxxx" <nouveau@xxxxxxxxxxxxxxxxxxxxx>, "dri-devel@xxxxxxxxxxxxxxxxxxxxx" <dri-devel@xxxxxxxxxxxxxxxxxxxxx>, "linux-mm@xxxxxxxxx" <linux-mm@xxxxxxxxx>, "Zhou, David\(ChunMing\)" <David1.Zhou@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>, "linux-rdma@xxxxxxxxxxxxxxx" <linux-rdma@xxxxxxxxxxxxxxx>, "amd-gfx@xxxxxxxxxxxxxxxxxxxxx" <amd-gfx@xxxxxxxxxxxxxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Ben Skeggs <bskeggs@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Ralph Campbell <rcampbell@xxxxxxxxxx>, John Hubbard <jhubbard@xxxxxxxxxx>, Jerome Glisse <jglisse@xxxxxxxxxx>, Dennis Dalessandro <dennis.dalessandro@xxxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Petr Cvek <petrcvekcz@xxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Mike Marciniszyn <mike.marciniszyn@xxxxxxxxx>, "Kuehling, Felix" <Felix.Kuehling@xxxxxxx>, "Deucher, Alexander" <Alexander.Deucher@xxxxxxx>, "Koenig, Christian" <Christian.Koenig@xxxxxxx>
- Delivery-date: Fri, 01 Nov 2019 19:51:36 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHVjcvOUfhzqykxXkO0v7SQaQq3BKdyANqAgAAA3wCABGiEgIAAB7AAgAANJwCAABzBgIAAIl8AgAABrwA=
- Thread-topic: [PATCH v2 14/15] drm/amdgpu: Use mmu_range_notifier instead of hmm_mirror
On Fri, Nov 01, 2019 at 07:45:22PM +0000, Yang, Philip wrote:
> > This must be done inside the notifier_lock, after checking
> > mmu_range_read_retry(), all handling of the struct page must be
> > structured like that.
> >
> Below change will fix this, then driver will call mmu_range_read_retry
> second time using same range->notifier_seq to check if range is
> invalidated inside amdgpu_cs_submit, this looks ok for me.
Lets defer this to some patch trying to fix it, I find it hard to
follow..
> @@ -868,6 +869,13 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo
> *bo, struct page **pages)
> goto out_free_pfns;
> }
>
> + mutex_lock(&adev->notifier_lock);
> +
> + if (mmu_range_read_retry(&bo->notifier, range->notifier_seq)) {
> + mutex_unlock(&adev->notifier_lock);
> + goto retry;
> + }
> +
> for (i = 0; i < ttm->num_pages; i++) {
> pages[i] = hmm_device_entry_to_page(range, range->pfns[i]);
> if (unlikely(!pages[i])) {
> @@ -875,10 +883,12 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo
> *bo, struct page **pages)
> i, range->pfns[i]);
> r = -ENOMEM;
>
> + mutex_unlock(&adev->notifier_lock);
> goto out_free_pfns;
> }
> }
Well, maybe?
The question now is what happens to 'pages' ? With this arrangment the
driver cannot touch 'pages' without also again going under the lock
and checking retry.
If it doesn't touch it, then lets just move this device_entry_to_page
to a more appropriate place?
I'd prefer it if the driver could be structured in the normal way,
with a clear locked region where the page list is handled..
Jason
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|