On 5/9/25 17:47, Matthew Brost wrote:
> On Fri, May 09, 2025 at 04:33:40PM +0100, Tvrtko Ursulin wrote:
>> Replace open-coded helper with the subsystem one.
>>
>
> You probably can just send this one by itself as it good cleanup and
> independent.
>
> Reviewed-by: Matthew Brost <matthew.brost(a)intel.com>
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Any objections that I start to push those patches to drm-misc-next or do you want to take this one through the i915 branch?
Regards,
Christian.
>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com>
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_wait.c | 7 +------
>> 1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
>> index 7127e90c1a8f..991666fd9f85 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
>> @@ -106,11 +106,6 @@ static void fence_set_priority(struct dma_fence *fence,
>> rcu_read_unlock();
>> }
>>
>> -static inline bool __dma_fence_is_chain(const struct dma_fence *fence)
>> -{
>> - return fence->ops == &dma_fence_chain_ops;
>> -}
>> -
>> void i915_gem_fence_wait_priority(struct dma_fence *fence,
>> const struct i915_sched_attr *attr)
>> {
>> @@ -126,7 +121,7 @@ void i915_gem_fence_wait_priority(struct dma_fence *fence,
>>
>> for (i = 0; i < array->num_fences; i++)
>> fence_set_priority(array->fences[i], attr);
>> - } else if (__dma_fence_is_chain(fence)) {
>> + } else if (dma_fence_is_chain(fence)) {
>> struct dma_fence *iter;
>>
>> /* The chain is ordered; if we boost the last, we boost all */
>> --
>> 2.48.0
>>
On Fri, May 9, 2025 at 2:58 PM Song Liu <song(a)kernel.org> wrote:
>
> On Fri, May 9, 2025 at 2:43 PM T.J. Mercier <tjmercier(a)google.com> wrote:
> >
> [...]
> > >
> > > Personally, I would prefer we just merge all the logic of
> > > create_udmabuf() and create_sys_heap_dmabuf()
> > > into create_test_buffers().
> >
> > That's a lot of different stuff to put in one place. How about
> > returning file descriptors from the buffer create functions while
> > having them clean up after themselves:
>
> I do like this version better. Some nitpicks though.
>
> >
> > -static int memfd, udmabuf;
> > +static int udmabuf;
>
> About this, and ...
>
> > static const char udmabuf_test_buffer_name[DMA_BUF_NAME_LEN] =
> > "udmabuf_test_buffer_for_iter";
> > static size_t udmabuf_test_buffer_size;
> > static int sysheap_dmabuf;
> > static const char sysheap_test_buffer_name[DMA_BUF_NAME_LEN] =
> > "sysheap_test_buffer_for_iter";
> > static size_t sysheap_test_buffer_size;
> >
> > -static int create_udmabuf(int map_fd)
> > +static int create_udmabuf(void)
> > {
> > struct udmabuf_create create;
> > - int dev_udmabuf;
> > - bool f = false;
> > + int dev_udmabuf, memfd, udmabuf;
> .. here.
>
> It is not ideal to have a global udmabuf and a local udmabuf.
> If we want the global version, let's rename the local one.
Ok let me change up the name of the aliasing variable to local_udmabuf.
> [...]
>
> >
> > static int create_test_buffers(int map_fd)
> > {
> > - int ret;
> > + bool f = false;
> > +
> > + udmabuf = create_udmabuf();
> > + sysheap_dmabuf = create_sys_heap_dmabuf();
> >
> > - ret = create_udmabuf(map_fd);
> > - if (ret)
> > - return ret;
> > + if (udmabuf < 0 || sysheap_dmabuf < 0)
> > + return -1;
>
> We also need destroy_test_buffers() on the error path here,
> or at the caller.
The caller does currently check to decide if it should bother running
the tests or not, and calls destroy_test_buffers() if not.
> > - return create_sys_heap_dmabuf(map_fd);
> > + return bpf_map_update_elem(map_fd, udmabuf_test_buffer_name,
> > &f, BPF_ANY) ||
> > + bpf_map_update_elem(map_fd, sysheap_test_buffer_name,
> > &f, BPF_ANY);
> > }
> >
> > static void destroy_test_buffers(void)
> > {
> > close(udmabuf);
> > - close(memfd);
> > close(sysheap_dmabuf);
>
> For the two global fds, let's reset them to -1 right after close().
>
> Thanks,
> Song
Will do, thanks.
On Sat, May 10, 2025 at 12:28:48AM +0800, Xu Yilun wrote:
> On Fri, May 09, 2025 at 07:12:46PM +0800, Xu Yilun wrote:
> > On Fri, May 09, 2025 at 01:04:58PM +1000, Alexey Kardashevskiy wrote:
> > > Ping?
> >
> > Sorry for late reply from vacation.
> >
> > > Also, since there is pushback on 01/12 "dma-buf: Introduce dma_buf_get_pfn_unlocked() kAPI", what is the plan now? Thanks,
> >
> > As disscussed in the thread, this kAPI is not well considered but IIUC
> > the concept of "importer mapping" is still valid. We need more
> > investigation about all the needs - P2P, CC memory, private bus
> > channel, and work out a formal API.
> >
> > However in last few months I'm focusing on high level TIO flow - TSM
> > framework, IOMMUFD based bind/unbind, so no much progress here and is
> > still using this temporary kAPI. But as long as "importer mapping" is
> > alive, the dmabuf fd for KVM is still valid and we could enable TIO
> > based on that.
>
> Oh I forgot to mention I moved the dmabuf creation from VFIO to IOMMUFD
> recently, the IOCTL is against iommufd_device.
I'm surprised by this.. iommufd shouldn't be doing PCI stuff, it is
just about managing the translation control of the device.
> According to Jason's
> opinion [1], TSM bind/unbind should be called against iommufd_device,
> then I need to do the same for dmabuf. This is because Intel TDX
> Connect enforces a specific operation sequence between TSM unbind & MMIO
> unmap:
>
> 1. STOP TDI via TDISP message STOP_INTERFACE
> 2. Private MMIO unmap from Secure EPT
> 3. Trusted Device Context Table cleanup for the TDI
> 4. TDI ownership reclaim and metadata free
So your issue is you need to shoot down the dmabuf during vPCI device
destruction?
VFIO also needs to shoot down the MMIO during things like FLR
I don't think moving to iommufd really fixes it, it sounds like you
need more coordination between the two parts??
Jason
On Thu, May 8, 2025 at 5:36 PM Song Liu <song(a)kernel.org> wrote:
>
> On Thu, May 8, 2025 at 11:20 AM T.J. Mercier <tjmercier(a)google.com> wrote:
> [...]
> > diff --git a/tools/testing/selftests/bpf/prog_tests/dmabuf_iter.c b/tools/testing/selftests/bpf/prog_tests/dmabuf_iter.c
> > new file mode 100644
> > index 000000000000..35745f4ce0f8
> > --- /dev/null
> > +++ b/tools/testing/selftests/bpf/prog_tests/dmabuf_iter.c
> > @@ -0,0 +1,224 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/* Copyright (c) 2025 Google */
> > +
> > +#include <test_progs.h>
> > +#include <bpf/libbpf.h>
> > +#include <bpf/btf.h>
> > +#include "dmabuf_iter.skel.h"
> > +
> > +#include <fcntl.h>
> > +#include <stdbool.h>
> > +#include <stdio.h>
> > +#include <stdlib.h>
> > +#include <string.h>
> > +#include <sys/ioctl.h>
> > +#include <sys/mman.h>
> > +#include <unistd.h>
> > +
> > +#include <linux/dma-buf.h>
> > +#include <linux/dma-heap.h>
> > +#include <linux/udmabuf.h>
> > +
> > +static int memfd, udmabuf;
>
> Global fds are weird. AFAICT, we don't really need them
> to be global? If we really need them to be global, please
> initialize them to -1, just in case we close(0) by accident.
Hmm, no we don't really need them to be global but I didn't really
want to pass all these variables around to all the setup and test
functions. The fd lifetimes are nearly the whole program lifetime
anyways, and just need to exist without actually being used for
anything. I'll add the -1 initialization as you suggest. If udmabuf
creation failed, we would have done a close(0) in
destroy_test_buffers() on the sysheap_dmabuf fd.
> > +static const char udmabuf_test_buffer_name[DMA_BUF_NAME_LEN] = "udmabuf_test_buffer_for_iter";
> > +static size_t udmabuf_test_buffer_size;
> > +static int sysheap_dmabuf;
> > +static const char sysheap_test_buffer_name[DMA_BUF_NAME_LEN] = "sysheap_test_buffer_for_iter";
> > +static size_t sysheap_test_buffer_size;