From: Joerg Roedel <joro@8bytes.org>
To: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Cc: kevin.tian@intel.com, alex.williamson@redhat.com,
ashok.raj@intel.com, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, christian.koenig@amd.com
Subject: Re: [PATCH 1/1] iommu: Bind process address spaces to devices
Date: Tue, 26 Feb 2019 14:02:04 +0100 [thread overview]
Message-ID: <20190226130204.GA23259@8bytes.org> (raw)
In-Reply-To: <559a7ef6-8591-3936-b208-3bbae555a15a@arm.com>
On Tue, Feb 26, 2019 at 12:49:15PM +0000, Jean-Philippe Brucker wrote:
> On 26/02/2019 11:17, Joerg Roedel wrote:
> > int iommu_sva_get_pasid(struct iommu_sva *handle);
> > void iommu_sva_set_exit_handler(struct iommu_sva *handle,
> > iommu_mm_exit_handler_t mm_exit);
>
> Ok sounds good. It doesn't look like this interface requires a lot of
> changes on my side (iommu_sva corresponds to the iommu_bond structure
> I've been using internally) but I might find problems while implementing it.
Great!
> Device drivers will also want to have some private data to easily
> identify the faulting or exiting context. How about:
>
> struct iommu_sva_ops {
> void (*mm_exit)(struct iommu_sva *handle, void *drvdata);
> };
> int iommu_sva_set_ops(struct iommu_sva *handle,
> const struct iommu_sva_ops *ops,
> void *drvdata);
Okay, we can also do it this way. But then please pass the drvdata via
the bind() call and not via set_ops(). Set_ops() should then really only
pass the call-backs, as the name implies.
> I now think that device driver should always call unbind() to release
> the iommu_sva handle, even if they got notified by mm_exit.
Yes, this should be required. I think it also makes driver
implementation easier because it doesn't need to care too much about
this special case.
Regards,
Joerg
next prev parent reply other threads:[~2019-02-26 13:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-20 14:27 [PATCH 0/1] IOMMU SVA device driver interface Jean-Philippe Brucker
2019-02-20 14:27 ` [PATCH 1/1] iommu: Bind process address spaces to devices Jean-Philippe Brucker
2019-02-26 11:17 ` Joerg Roedel
2019-02-26 12:49 ` Jean-Philippe Brucker
2019-02-26 13:02 ` Joerg Roedel [this message]
2019-02-27 21:41 ` Jacob Pan
2019-02-28 1:10 ` Tian, Kevin
2019-02-28 18:53 ` Jacob Pan
2019-02-28 12:19 ` Jean-Philippe Brucker
2019-02-28 18:32 ` Jacob Pan
2019-02-28 14:09 ` Joerg Roedel
2019-02-28 21:15 ` Jacob Pan
2019-02-28 22:04 ` Raj, Ashok
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190226130204.GA23259@8bytes.org \
--to=joro@8bytes.org \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=christian.koenig@amd.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jean-philippe.brucker@arm.com \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.