On 10/23/26 02:36, Val Packett wrote:
> On 10/22/26 9:26 AM, Christian König wrote:
>> On 10/21/26 22:16, Val Packett wrote:
>>> On 10/21/26 10:43 AM, Christian König wrote:
>>>> [..]
>>>>> The buffer lifecycle coordination we need this for applies to KVM as well
>>>>> and it generally doesn't make sense to have this as a provider-specific
>>>>> thing since it's not related to the provider in any way, it's just
>>>>> something we want from dmabufs in general.
>>>> I wouldn't put that on the DMA-buf file descriptor where basically anybody can mess with it. That is just an recipe for trouble.
>>>>
>>>> The better approach seems to be putting it into the udmabuf_ioctl(), so that from the very beginning you add the eventfd which signals when the udmabuf is released.
>>>>
>>>> If we need that for more implementations than just udmabuf, we can potentially add it to dma_buf_export_info so that exporters can provide the eventfd file descriptor directly on creation.
>>> Well, we already need it with both udmabuf and gntdev-dmabuf..
>>>
>>> Involving the exporter sounds really annoying when it's not something exporter dependent really.. What if the policy is just "only one eventfd ever" i.e. the first call of the ioctl succeeds but later calls on the same dmabuf return an error?
>> No, exactly that is what I'm trying to avoid.
>>
>> Nobody except the original creater should be able to insert an eventfd here.
>
> If there's no replacement allowed anymore, what could possibly be harmful/undesirable about "someone else" being able to do this?
>
> With a "first caller only" policy, the original creator already can be 100% sure that no one else is able to insert an eventfd:
Ok that sounds like you my argumentation wasn't fully clear: That approach is exactly what I try to avoid!
> If the original creator calls this API before sending the fd to anyone else, well, the original creator *is* the first caller, that's it.
>
> Otherwise, i.e. if the original creator is not interested in this API.. it's unlikely a different process would use it, but if one does for some reason, I don't see any negative consequences from that?
First of all if this gets added as common DMA-buf API the functionality suddenly becomes available to every exporter, not just the ones who explicitly implement it.
That in turn would be rather questionable because lifetime is something only the exporter of a buffer can fully deal with.
For example it is very common that the exporter delegates cleanup from the ->release callback to a work item and your whole approach with the eventfd on the DMA-buf then doesn't work any more.
Then second when the add this as common DMA-buf functionality then it should be usable by everybody and not just the first one who asks. Otherwise you can run into all kind mess with that when you give a DMA-buf where the eventfd slot is already used up to some other process which expects to use that functionality.
For now that functionality only seems to make sense for the original creator and a limited amount of exporters where it actually works. So my suggestion is to either add some functionality to the exporter(s) or add some common functionality to dma_buf_export_info to aid exporters with their implementation.
Apart from that the approach with the eventfd looks perfectly fine to me.
Regards,
Christian.
>
>
>
> Thanks,
> ~val
On Fri, Oct 23, 2026 at 08:39:28AM +0200, Tomeu Vizoso wrote:
> A firmware may drive the core's timers, which need their power domains
> held; the remoteproc driver does not hold them, so let the DSP node
> reference them for a driver that attaches to the running core to hold.
>
> Assisted-by: LLM
> Signed-off-by: Tomeu Vizoso <tomeu(a)tomeuvizoso.net>
>
> ---
>
> v3:
> - Initial version
> ---
> .../devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
> index d6319c8e96f8..80eaef0a19b8 100644
> --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
> @@ -76,6 +76,23 @@ properties:
> # Optional properties:
> # --------------------
>
> + power-domains:
> + description: |
> + Power domains of the SoC timers the running firmware ticks on and
> + times its work out with. The firmware programs these timers itself
> + and makes no power request for them, and the timers' own nodes are
> + reserved for it, so nothing else requests their power; a client
> + driver of the firmware holds them on while it drives the processor.
> + The processor's own power is managed through ti,sci-dev-id, not here.
> + items:
> + - description: power domain of the first timer
first timer
> + - description: power domain of the second timer
second timer
No need to say that power domain is a power domain.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)oss.qualcomm.com>
Best regards,
Krzysztof
On Fri, Oct 23, 2026 at 08:39:27AM +0200, Tomeu Vizoso wrote:
> Allow specifying a second sub-mailbox that could be used by the firmware
> in addition to the first one, which is taken by remoteproc.
>
> This is required by firmware that doesn't use rpmsg for their
> communication with the Linux kernel.
>
> Assisted-by: LLM
Drop
> Signed-off-by: Tomeu Vizoso <tomeu(a)tomeuvizoso.net>
DCO mismatch.
>
> ---
>
> v3:
> - Initial version
> ---
> .../devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
> index 278b88b7f906..d6319c8e96f8 100644
> --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
> @@ -51,10 +51,12 @@ properties:
>
> mboxes:
> description: |
> - OMAP Mailbox specifier denoting the sub-mailbox, to be used for
> - communication with the remote processor. This property should match
> - with the sub-mailbox node used in the firmware image.
> - maxItems: 1
> + OMAP Mailbox specifiers denoting the sub-mailboxes allotted to
> + communication with the remote processor. The first is the one the
> + remoteproc core uses and should match the sub-mailbox node used in the
> + firmware image. The second is optional.
Instead list the items with description and minItems: 1. Don't repeat
constraints in free form text.
> + minItems: 1
Best regards,
Krzysztof
PCI P2PDMA applies Request and Completion Redirect throughout both paths.
This misclassifies asymmetric and nested switches, and reports one answer
for every kind of TLP.
Three ACS controls act on TLP attributes the client chooses rather than
on the topology: Translation Blocking and Direct Translated P2P act on
a Request's Address Type, and Completion Redirect skips Completions carrying
Relaxed Ordering.
Evaluate each direction at the path divergence, decide every class from the
one walk, and treat a client with ATS enabled as translating unless its
driver declares per-mapping ATS.
This completes the P2PDMA side; dma-buf and mlx5 follow separately.
Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com>
---
Changes in v9:
- Removed dmabuf patches for now.
- Removed mlx5 per-mapping ATS declaration for now; it comes back with
the dmabuf patches.
- Link to v8: https://patch.msgid.link/20260928-fix-p2p-acs-v4-0-v8-0-404453b9c435@nvidia…
Changes in v8:
- Added extra Reviewed-by from Logan.
- Added patches to take care of ATS per-device vs. per-mapping option
- Link to v7: https://patch.msgid.link/20260920-fix-p2p-acs-v4-0-v7-0-ca0828ab697c@nvidia…
Changes in v7:
- Removed "Document pdev->p2pdma lifetime rules" patch, it gives nothing
after p2pmem fix.
- Split dmabuf patch.
- Tushar retested the series, so added his Tested-by.
- Added Logan's ROB tags and fixed minor documentation issues pointed
by him.
- Link to v6: https://lore.kernel.org/all/20260914-fix-p2p-acs-v4-0-v6-0-5ef07ec9ef06@nvi…
Changes in v6:
- Changed DMABUF to use callbacks and not directly stored pointer.
- Link to v5: https://patch.msgid.link/20260910-fix-p2p-acs-v4-0-v5-0-856087f63c0d@nvidia…
Changes in v5:
- Rebase on the posted fixes.
- Dropped tags from changed patches.
- Remove Egress Control Vector interpretation and coverage.
- Keep enabled Egress Control conservative as a Request redirect.
- Use pci_dbg()/dev_dbg() for diagnostics and drop the "debug" prefix.
- Removed code comments from "Document the pdev->p2pdma lifetime and RCU
rules" patch and reduced description to actual lifetime explanation.
- Added note that Linux assumes that TLPs are in strict-ordering and
untranslated.
- Added code to calculate p2p paths per-TLP type.
- Converted mlx5 to use that new proposed API.
- Link to https://patch.msgid.link/20260821-fix-p2p-acs-v4-0-v4-0-94426b96de73@nvidia…
Changes in v4:
- Reject ACS Violations and unreadable routing state instead of treating
them as host-bridge redirects
- Added Tested-by tags from Tushar Dave
- Added support to asymmetric ACS routing
- Limited redirect checks to the two ports at the path divergence
- Added standalone ACS routing diagnostics for hardware retesting
- Dropped " PCI: Account for Direct Translated P2P in ACS isolation checks" patch
- Link to v3: https://patch.msgid.link/20260811-fix-p2p-acs-v3-0-efc488ee7c03@nvidia.com
Changes in v3:
- Fixed pci_p2pdma_add_resource() error unwinding
- Made pdev->p2pdma teardown wait unconditionally for RCU readers
- Restricted pci_p2pmem_find_many() to pool-backed providers
- Documented the pdev->p2pdma lifetime and RCU rules
- Fixed calc_map_type_and_dist() handling of the verbose argument
- Required the ACS port and target to share a bus before indexing the
Egress Control Vector
- Gave pci_acs_enabled() and pci_acs_path_enabled() a scope, so the ACS
Direct Translated P2P rule no longer stops pci_enable_pasid() from
enabling PASID
- Dropped "Report ACS ports when the paths share no upstream bridge":
the mapping type cannot change without a shared upstream bridge, so
the pci=disable_acs_redir= hint was not actionable there and the ACS
walk only cost config space reads
- Folded the Request Redirect rule into pci_acs_rr_ineffective(), so
pci_acs_flags_enabled() and the Intel SPT PCH quirk share one copy
- Renamed pci_acs_egress_ctrl_set() to pci_acs_egress_ctrl_is_set(), it
reads the bit rather than setting it
- Reworded the blocked-path warning: ACS may also leave the direct route
indeterminate rather than blocked
- Added KUnit coverage for the shared-bus guard, a device with no ACS
capability and an unreadable ACS Control register
- Added the missing Fixes: tags, a second one on the
pci_p2pdma_add_resource() unwinding fix (the dangling devres action
dates to f58ef9d1d135) and one on the Egress Control isolation change
- Link to v2: https://patch.msgid.link/20260806-fix-p2p-acs-v2-0-0cec14812965@nvidia.com
Changes in v2:
- Added Logan's ROB tags
- Added commas in Documentation patch
- Link to v1: https://patch.msgid.link/20260802-fix-p2p-acs-v1-0-a7c5eb64fff6@nvidia.com
---
Leon Romanovsky (18):
PCI/P2PDMA: Document the TLP attribute assumptions
PCI/P2PDMA: Derive routing from directional ACS controls
PCI: Reject unreadable ACS controls in isolation checks
PCI/P2PDMA: Evaluate ACS controls at the path divergence
PCI/P2PDMA: Document directional ACS routing
PCI/P2PDMA: Collect the path's ACS controls before deciding
PCI/P2PDMA: Answer routing per TLP class
PCI/P2PDMA: Route Relaxed Ordering Completions directly
PCI/P2PDMA: Reject Translated Requests blocked by Translation Blocking
PCI/P2PDMA: Route Translated Requests under Direct Translated P2P
PCI/P2PDMA: Log detailed ACS routing diagnostics
PCI/P2PDMA: Add KUnit tests for the ACS routing decisions
PCI/P2PDMA: Test the ACS P2P routing walk
PCI: Add KUnit coverage for ACS isolation checks
PCI/P2PDMA: Document TLP-class routing
PCI/P2PDMA: Let a client declare that it selects ATS per mapping
PCI/P2PDMA: Evaluate the ATS path for clients with ATS enabled
PCI/P2PDMA: Test the routing of clients with ATS enabled
Documentation/admin-guide/kernel-parameters.txt | 15 +-
Documentation/driver-api/pci/p2pdma.rst | 80 +++
drivers/pci/Kconfig | 15 +
drivers/pci/Makefile | 1 +
drivers/pci/p2pdma.c | 719 ++++++++++++++++++--
drivers/pci/pci.c | 7 +-
drivers/pci/pci.h | 58 ++
drivers/pci/pci_acs_test.c | 860 ++++++++++++++++++++++++
drivers/pci/quirks.c | 6 +-
include/linux/pci-p2pdma.h | 12 +-
10 files changed, 1687 insertions(+), 86 deletions(-)
---
base-commit: 08dbfad3f5040f5bdb6c529da20d6d4e81fefd72
change-id: 20260821-fix-p2p-acs-v4-0-e72455e3a261
prerequisite-message-id: <20260830-batch-p2p-fixes-v1-0-5044e8dfbe2e(a)nvidia.com>
prerequisite-patch-id: 6b25c7fcf164cdfc14e9fac5b908d97fcf6509d7
prerequisite-patch-id: 0d083c281001365aae4b35544cf28891a6ab9a96
prerequisite-patch-id: bfd9dabf271f3cc9a3a61f46387d20c20311363d
prerequisite-patch-id: fad0275efc722830fc591509506c0a5e4f581073
prerequisite-patch-id: 0c83bee688fec1f6d1564654df7c630fa6a4a978
Best regards,
--
Leon Romanovsky <leonro(a)nvidia.com>
On 23/10/2026 10:10, Jayant Shekhar wrote:
>>> +properties:
>>> + reg:
>>> + maxItems: 1
>>> + description: Index of this DSI host among its siblings.
>>> +
>>> + status: true
>> I see slop, I finished here. Mind this maintainers summit words - if you
>> use AI, you must use good one, not the shloppy slop.
>
>
> Will remove this in v2.
And please also remove other sloppy-code produced by your AI as well.
Best regards,
Krzysztof
On 10/22/26 08:52, Alistair Popple wrote:
> On 2026-10-21 at 23:37 +1100, Jason Gunthorpe <jgg(a)nvidia.com> wrote...
>> On Wed, Oct 21, 2026 at 08:24:40AM +0200, Thomas Hellström wrote:
>>>> struct dma_buf_mapping_exp_ops
>>>> Base type for the per-mapping type exporter provided functions.
>>>> This
>>>> would be the map/unmap callbacks. Each mapping type can provide
>>>> its own
>>>> functions for map/unmap type operations with optimal type
>>>> signatures.
>>>
>>> Does it make sense to try to land this patch first, plus a conversion
>>> of pcie_p2p so we could agree on what the contract should look like?
>>
>> I think it would be good to focus on this patch as the main 'crux' of
>> the series. The API contract is the main agreement. I'm relucant to
>> merge code that has no users, so it woudl be ebtter to go up to at
>> least through SGT.
>>
>>> s/mapping/interconnect/? My gut feeling is that "interconnect" best
>>> describes what's typically going on, but "mapping" perhaps better
>>> describes all cases.
>>
>> My intention was to cover more than just the phyiscal transport. We do
>> really want to get away from scatterlist, so having PCIe map with
>> scatterlist and PCIe map with <something else> still ends up with two
>> mapping types in the system.
>>
>> This is why I choose the name over interconnect.
>>
>>> Location of common protocols which typically carry cross-subsystem
>>> dependencies?
>>> drivers/dma-buf/mapping_types? drivers/dma-buf/interconnects?
>>
>> I'd encourage people to design more like PCI where the actual
>> *interconnect* has its own home and there is just some minor call outs
>> from dmabuf to help the matching logic.
>>
>>> As discussed previously:
>>> Agree on theoretically possible matches at attach time, Match at
>>> mapping time and guarantee the match is valid until
>>> invalidate_mappings().
>>
>> I was thinking about this some more, and I'm less sure now.
>>
>> If I think about mlx5, in a multi-path PCIe configuration, it can move
>> the translation around within a single PCIe path, but it cannot move
>> it to another path without creating disruption for the
>> application. This is a HW limitation in how the internal routing
>> works..
>>
>> I strongly suspect this will be the norm for any hardware that doesn't
>> rely on decorated page tables to select the IO path..
>>
>> So, while I agree we should support hardware that can fully change the
>> path on each and every map, we also need to suport hardware that must
>> pin the path during attach.
>>
>> Probably this points to needing a 'pin' operation for the mapping
>> selection after attach.
>
> If I'm understanding things correctly we're expecting a change in path between
> attach and map time to be rare in practice. Therefore the need to handle this
> case is mostly as a fallback to not break things. So instead of pinning could
> new attachments just invalidate all existing incompatible attachments on the
> list by setting eg. attach->valid = 0?
No, that would result in ping/pong behavior which is something we explicitly try to avoid.
This is also not something uncommon, it happens multiple times a second on a standard X11 Linux desktop when a new buffer is started to be scanned out on an A+A or A+I laptop.
Regards,
Christian.
>
> Attachment could also scan existing attachments to preferentially pick matching
> mapping_types that are compatible with existing attachments, thus avoiding
> invalidation where possible.
>
> Map time functions (eg. dma_buf_sgt_map_attachment) would check attach->valid
> and return a failure if a subsequent attachment/event had invalidated the
> mapping type.
>
> Importers with invalidated attachments would then have to retry creating the
> attachment, probably getting a different mapping_type. Would this be acceptable?
> Or do some importers absolutely require the mapping_type to never change once
> the intial match/attachment has happened?
>
> - Alistair
>
>>>> +/*
>>>> + * Match items are generated by the importer using the
>>>> DMA_BUF_IMAPPING_*() and
>>>> + * the exporter using the DMA_BUF_EMAPPING_*() functions. Each
>>>> mapping type
>>>> + * defines its own signature with its own data to make the match and
>>>> attachment.
>>>> + */
>>>> +struct dma_buf_mapping_match {
>>>> + const struct dma_buf_mapping_type *type;
>>>> + const struct dma_buf_mapping_exp_ops *exp_ops;
>>>> + union {
>>>> + /* Each mapping_type has unique match parameters
>>>> here */
>>>> + };
>>>
>>> Do we really need to add all global mapping types here? Then we'd need
>>> something for driver-private mapping types as well.
>>
>> IIRC it is fixed size up front like this because of how the
>> structure's memory is managed in this design..
>>
>> If you want a driver private thing then I'd add a 'u64
>> driver_private[2]' to the union and the driver can cast over it.
>>
>> But this is the kernel, if you want to add an xe_mapping_type, then
>> just add it. I don't know we need to do driver private things.
>>
>> Jason
* On Thu, 2026-10-22 at 22:17 +1100, Alistair Popple wrote:
> On 2026-10-22 at 18:25 +1100, Thomas Hellström
> <thomas.hellstrom(a)linux.intel.com> wrote...
> > On Thu, 2026-10-22 at 17:52 +1100, Alistair Popple wrote:
> > > On 2026-10-21 at 23:37 +1100, Jason Gunthorpe <jgg(a)nvidia.com>
> > > wrote...
> > > > On Wed, Oct 21, 2026 at 08:24:40AM +0200, Thomas Hellström
> > > > wrote:
> > > > > > struct dma_buf_mapping_exp_ops
> > > > > > Base type for the per-mapping type exporter provided
> > > > > > functions.
> > > > > > This
> > > > > > would be the map/unmap callbacks. Each mapping type can
> > > > > > provide
> > > > > > its own
> > > > > > functions for map/unmap type operations with optimal
> > > > > > type
> > > > > > signatures.
> > > > >
> > > > > Does it make sense to try to land this patch first, plus a
> > > > > conversion
> > > > > of pcie_p2p so we could agree on what the contract should
> > > > > look
> > > > > like?
> > > >
> > > > I think it would be good to focus on this patch as the main
> > > > 'crux'
> > > > of
> > > > the series. The API contract is the main agreement. I'm
> > > > relucant to
> > > > merge code that has no users, so it woudl be ebtter to go up to
> > > > at
> > > > least through SGT.
> > > >
> > > > > s/mapping/interconnect/? My gut feeling is that
> > > > > "interconnect"
> > > > > best
> > > > > describes what's typically going on, but "mapping" perhaps
> > > > > better
> > > > > describes all cases.
> > > >
> > > > My intention was to cover more than just the phyiscal
> > > > transport. We
> > > > do
> > > > really want to get away from scatterlist, so having PCIe map
> > > > with
> > > > scatterlist and PCIe map with <something else> still ends up
> > > > with
> > > > two
> > > > mapping types in the system.
> > > >
> > > > This is why I choose the name over interconnect.
> > > >
> > > > > Location of common protocols which typically carry cross-
> > > > > subsystem
> > > > > dependencies?
> > > > > drivers/dma-buf/mapping_types? drivers/dma-buf/interconnects?
> > > >
> > > > I'd encourage people to design more like PCI where the actual
> > > > *interconnect* has its own home and there is just some minor
> > > > call
> > > > outs
> > > > from dmabuf to help the matching logic.
> > > >
> > > > > As discussed previously:
> > > > > Agree on theoretically possible matches at attach time, Match
> > > > > at
> > > > > mapping time and guarantee the match is valid until
> > > > > invalidate_mappings().
> > > >
> > > > I was thinking about this some more, and I'm less sure now.
> > > >
> > > > If I think about mlx5, in a multi-path PCIe configuration, it
> > > > can
> > > > move
> > > > the translation around within a single PCIe path, but it cannot
> > > > move
> > > > it to another path without creating disruption for the
> > > > application. This is a HW limitation in how the internal
> > > > routing
> > > > works..
> > > >
> > > > I strongly suspect this will be the norm for any hardware that
> > > > doesn't
> > > > rely on decorated page tables to select the IO path..
> > > >
> > > > So, while I agree we should support hardware that can fully
> > > > change
> > > > the
> > > > path on each and every map, we also need to suport hardware
> > > > that
> > > > must
> > > > pin the path during attach.
> > > >
> > > > Probably this points to needing a 'pin' operation for the
> > > > mapping
> > > > selection after attach.
> > >
> > > If I'm understanding things correctly we're expecting a change in
> > > path between
> > > attach and map time to be rare in practice. Therefore the need to
> > > handle this
> > > case is mostly as a fallback to not break things. So instead of
> > > pinning could
> > > new attachments just invalidate all existing incompatible
> > > attachments
> > > on the
> > > list by setting eg. attach->valid = 0?
> >
> > I agree, (although I think the "invalidate_attachment" needs to be
> > discussed). In the end the importer should be given a choice,
> > either
> > pin and accept that subsequent attachers might see errors or
> > accept
> > app disruption.
> >
> > >
> > > Attachment could also scan existing attachments to preferentially
> > > pick matching
> > > mapping_types that are compatible with existing attachments, thus
> > > avoiding
> > > invalidation where possible.
> >
> > Current design appears to be that attach only determines the set of
> > theoretically possible mapping types, disregarding other
> > attachments.
> > Taking other attachments into account is also problematic because
> > the
> > dma-resv lock is not held.
>
> Oh I see. Do you foresee any problems just taking the dma-resv lock
> to walk the
> current attachments? If so we could probably resolve it with RCU, but
> I'd rather
> keep it simple if we can.
It looks like dma_buf_dynamic_attach() actually takes the dma_resv lock
to update the attachment list, so that should work. Provided we want to
take existing attachments into account already at this stage.
Need to take care, though, not to have the resv lock held over the ops-
>attach callback into the driver.
>
> > Looking at current GPU drivers, what you describe above is
> > typically
> > done at pin() time, but if some importers want an early very likely
> > decision on what mapping_type to use, one could introduce a
> > separate
> > function that match the mapping_types, but that would be very
> > similar
> > to the map() function but without returning a sgt/mapping, or a
> > pin()
> > without actually pinning. One could reuse the invalidate_mappings()
> > callback to indicate the mapping type is no longer valid?
>
> I did wonder about that, but a callback for attachment invalidation
> seems like
> it might be a pain for importers to syncrhonize with. What I'm
> thinking, which I
> think is similar to what you describe, is something like the
> following:
>
> 1. Importer gets the likley attachment by passing a list of mapping
> types in
> prefered order to dma_buf_mapping_attach() which returns the
> dma_buf_attachment
> that would work based on current attachments and what the exporter
> provides:
>
>
Something like this sounds OK, although given Jason's use-case, I added
some comments:
> attach = dma_buf_mapping_attach(...)
>
Just filter out impossible mappings.
> 2. Takes dmabuf->resv lock.
dma_buf_match_mapping_type(); Determines a mapping that is valid until
the next invalidate_mappings(). NOP if a valid mapping already exists.
Allows masking mapping_types.
This allows Jason's use-case while keeping the attachment as a
callback anchor.
>
> 3. Pins the attachment (if required):
dma_buf_match_mapping_type(); Determines a mapping that is valid until
the next invalidate_mappings(). NOP if a valid mapping already exists.
Allows masking mapping_types.
This allows Jason's use-case while keeping the attachment as a
callback anchor.
>
> rc = dma_buf_pin(attach)
This would implicitly pin also the mapping_type, but question is what
happens if a link is severed? Then we'd want an invalidate_mappings()
to re-negotiate the mapping type, but a pinned dma-buf that receives an
invalidate_mappings() is revoked by definition.
>
> DMA-BUF core revalidates the attachment is still valid (ie. by
> checking the
> match again or via some other mechanism to detect the attachment
> path/location
> has changed such as a sequence/generation number).
Since the resv is locked, nothing could have changed since
dma_buf_match_mapping_type();
/Thomas
>
> On error the importer can either fail or try to create a new
> attachment.
>
> 4. Map
>
> rc = dma_buf_[sgt|pcie_p2p]_map(attach, ...)
>
> Follows the same revalidation process as dma_buf_pin().
>
> Thoughts?
>
> - Alistair
>
> > /Thomas
> >
> >
> > >
> > > Map time functions (eg. dma_buf_sgt_map_attachment) would check
> > > attach->valid
> > > and return a failure if a subsequent attachment/event had
> > > invalidated
> > > the
> > > mapping type.
> > >
> > > Importers with invalidated attachments would then have to retry
> > > creating the
> > > attachment, probably getting a different mapping_type. Would this
> > > be
> > > acceptable?
> > > Or do some importers absolutely require the mapping_type to never
> > > change once
> > > the intial match/attachment has happened?
> > >
> > > - Alistair
> > >
> > > > > > +/*
> > > > > > + * Match items are generated by the importer using the
> > > > > > DMA_BUF_IMAPPING_*() and
> > > > > > + * the exporter using the DMA_BUF_EMAPPING_*() functions.
> > > > > > Each
> > > > > > mapping type
> > > > > > + * defines its own signature with its own data to make the
> > > > > > match and
> > > > > > attachment.
> > > > > > + */
> > > > > > +struct dma_buf_mapping_match {
> > > > > > + const struct dma_buf_mapping_type *type;
> > > > > > + const struct dma_buf_mapping_exp_ops *exp_ops;
> > > > > > + union {
> > > > > > + /* Each mapping_type has unique match
> > > > > > parameters
> > > > > > here */
> > > > > > + };
> > > > >
> > > > > Do we really need to add all global mapping types here? Then
> > > > > we'd
> > > > > need
> > > > > something for driver-private mapping types as well.
> > > >
> > > > IIRC it is fixed size up front like this because of how the
> > > > structure's memory is managed in this design..
> > > >
> > > > If you want a driver private thing then I'd add a 'u64
> > > > driver_private[2]' to the union and the driver can cast over
> > > > it.
> > > >
> > > > But this is the kernel, if you want to add an xe_mapping_type,
> > > > then
> > > > just add it. I don't know we need to do driver private things.
> > > >
> > > > Jason
On 10/21/26 22:16, Val Packett wrote:
>
> On 10/21/26 10:43 AM, Christian König wrote:
>> [..]
>>> The buffer lifecycle coordination we need this for applies to KVM as well
>>> and it generally doesn't make sense to have this as a provider-specific
>>> thing since it's not related to the provider in any way, it's just
>>> something we want from dmabufs in general.
>> I wouldn't put that on the DMA-buf file descriptor where basically anybody can mess with it. That is just an recipe for trouble.
>>
>> The better approach seems to be putting it into the udmabuf_ioctl(), so that from the very beginning you add the eventfd which signals when the udmabuf is released.
>>
>> If we need that for more implementations than just udmabuf, we can potentially add it to dma_buf_export_info so that exporters can provide the eventfd file descriptor directly on creation.
>
> Well, we already need it with both udmabuf and gntdev-dmabuf..
>
> Involving the exporter sounds really annoying when it's not something exporter dependent really.. What if the policy is just "only one eventfd ever" i.e. the first call of the ioctl succeeds but later calls on the same dmabuf return an error?
No, exactly that is what I'm trying to avoid.
Nobody except the original creater should be able to insert an eventfd here.
Regards,
Christian.
> That should remove the concern about one user messing with another's events (and avoid the concurrent replacement issue sashiko-bot warned about)..
>
> Thanks,
> ~val
>