On Thu, Jul 12, 2018, 3:31 AM Michel Dänzer <michel at daenzer.net> wrote:
> On 2018-07-12 02:47 AM, Marek Olšák wrote:
> > From: Marek Olšák <marek.olsak at amd.com>
> >
> > ---
> > amdgpu/amdgpu.h | 7 ++++++-
> > amdgpu/amdgpu_bo.c | 4 ++++
> > 2 files changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
> > index 36f91058..be83b457 100644
> > --- a/amdgpu/amdgpu.h
> > +++ b/amdgpu/amdgpu.h
> > @@ -77,21 +77,26 @@ struct drm_amdgpu_info_hw_ip;
> > *
> > */
> > enum amdgpu_bo_handle_type {
> > /** GEM flink name (needs DRM authentication, used by DRI2) */
> > amdgpu_bo_handle_type_gem_flink_name = 0,
> >
> > /** KMS handle which is used by all driver ioctls */
> > amdgpu_bo_handle_type_kms = 1,
> >
> > /** DMA-buf fd handle */
> > - amdgpu_bo_handle_type_dma_buf_fd = 2
> > + amdgpu_bo_handle_type_dma_buf_fd = 2,
> > +
> > + /** KMS handle, but re-importing as a DMABUF handle through
> > + * drmPrimeHandleToFD is forbidden. (Glamor does that)
> > + */
> > + amdgpu_bo_handle_type_kms_noimport = 3,
> > };
> >
> > /** Define known types of GPU VM VA ranges */
> > enum amdgpu_gpu_va_range
> > {
> > /** Allocate from "normal"/general range */
> > amdgpu_gpu_va_range_general = 0
> > };
> >
> > enum amdgpu_sw_info {
> > diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
> > index 9e37b149..d29be244 100644
> > --- a/amdgpu/amdgpu_bo.c
> > +++ b/amdgpu/amdgpu_bo.c
> > @@ -234,20 +234,22 @@ int amdgpu_bo_export(amdgpu_bo_handle bo,
> > case amdgpu_bo_handle_type_gem_flink_name:
> > r = amdgpu_bo_export_flink(bo);
> > if (r)
> > return r;
> >
> > *shared_handle = bo->flink_name;
> > return 0;
> >
> > case amdgpu_bo_handle_type_kms:
> > amdgpu_add_handle_to_table(bo);
> > + /* fall through */
> > + case amdgpu_bo_handle_type_kms_noimport:
> > *shared_handle = bo->handle;
> > return 0;
>
> What is the rationale for this? I.e. why do you want to not store some
> handles in the hash table?
Because I have the option.
And how can code using
> amdgpu_bo_handle_type_kms_noimport be sure that the BO will never be
> re-imported via dma-buf?
>
That's for the user to decide and prove when it's safe.
> The experience with the previous patch has shown that it's hard to keep
> track of all possible ways in which BOs are imported, and that if we
> miss one, this breaks pretty spectacularly.
>
You are assuming that it will be used incorrectly based on your previous
bad experience. All I need to do is not to hand the handle to components
that would misuse it.
Marek
>
> --
> Earthling Michel Dänzer | http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20180712/0ea568fc/attachment.html>
