On Wed, Dec 08, 2021 at 10:31:58PM +1100, Alistair Popple wrote:
> On Tuesday, 7 December 2021 5:52:43 AM AEDT Alex Sierra wrote:
> > Avoid long term pinning for Coherent device type pages. This could
> > interfere with their own device memory manager.
> > If caller tries to get user device
On Mon, Dec 06, 2021 at 12:52:51PM -0600, Alex Sierra wrote:
> The intention is to test device coherent type pages that have been
> called through get user pages with PIN_LONGTERM flag set.
>
> Signed-off-by: Alex Sierra
> tools/testing/selftests/vm/Makefile| 2 +-
>
On Fri, Dec 03, 2021 at 12:51:44PM +0900, Shunsuke Mie wrote:
> Hi maintainers,
>
> Could you please review this patch series?
Why is it RFC?
I'm confused why this is useful?
This can't do copy from MMIO memory, so it shouldn't be compatible
with things like Gaudi - does something prevent
On Thu, Nov 04, 2021 at 02:30:20PM +0200, Joonas Lahtinen wrote:
> Quoting Christoph Hellwig (2021-11-02 09:05:34)
> > Remove the separately included Makefile and just use the relative
> > reference from the main i915 Makefile as for source files in other
> > subdirectories.
>
> The thinking
drivers/gpu/drm/i915/gvt/gvt.c | 291 ---
> drivers/gpu/drm/i915/gvt/gvt.h | 6 -
> drivers/gpu/drm/i915/gvt/kvmgt.c | 264 +++-
> 4 files changed, 260 insertions(+), 302 deletions(-)
> delete mode 100644 drivers/gpu/drm/i
tainer_of().
This should be using vfio_register_emulated_iommu_dev(), right?
I expect drivers using the pin API to use the emulated_iommu_dev()
interface at least..
Otherwise this looks good
Reviewed-by: Jason Gunthorpe
Jason
On Tue, Nov 02, 2021 at 08:05:59AM +0100, Christoph Hellwig wrote:
> Merge these into their only callers.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 129 ++-
> 1 file changed, 60 insertions(+), 69 deletions(-)
5/gvt/kvmgt.c | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
5/gvt/kvmgt.c | 28 +---
> 1 file changed, 9 insertions(+), 19 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Tue, Nov 02, 2021 at 08:05:56AM +0100, Christoph Hellwig wrote:
> All the dmabufs are torn down when th VGPU is released, so there is
> no need for extra refcounting here.
>
> Based on an patch from Jason Gunthorpe.
>
> Signed-off-by: Christoph Hellwig
> ---
>
(-)
> delete mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h
> delete mode 100644 drivers/gpu/drm/i915/gvt/mpt.h
Reviewed-by: Jason Gunthorpe
Jason
| 1 +
> drivers/gpu/drm/i915/gvt/hypercall.h | 2 --
> drivers/gpu/drm/i915/gvt/kvmgt.c | 4 +---
> drivers/gpu/drm/i915/gvt/mpt.h | 15 ---
> 5 files changed, 3 insertions(+), 33 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
ons(+), 57 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
gvt/kvmgt.c | 6 ++
> drivers/gpu/drm/i915/gvt/mpt.h| 28 ---
> drivers/gpu/drm/i915/gvt/page_track.c | 8
> 5 files changed, 9 insertions(+), 38 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
/gvt/kvmgt.c | 16
> drivers/gpu/drm/i915/gvt/mpt.h | 14 --
> 4 files changed, 5 insertions(+), 35 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
| 1 -
> drivers/gpu/drm/i915/gvt/kvmgt.c | 17 -
> drivers/gpu/drm/i915/gvt/mpt.h | 17 -
> 4 files changed, 18 insertions(+), 37 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
/i915/gvt/interrupt.c | 38 +++-
> drivers/gpu/drm/i915/gvt/kvmgt.c | 24 --
> drivers/gpu/drm/i915/gvt/mpt.h | 37 ---
> 4 files changed, 37 insertions(+), 63 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
/gvt/kvmgt.c | 3 +--
> drivers/gpu/drm/i915/gvt/mpt.h | 16
> drivers/gpu/drm/i915/gvt/vgpu.c | 2 +-
> 5 files changed, 3 insertions(+), 20 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
> drivers/gpu/drm/i915/gvt/kvmgt.c | 6 ++
> drivers/gpu/drm/i915/gvt/mpt.h | 32
> drivers/gpu/drm/i915/gvt/vgpu.c | 6 +++---
> 5 files changed, 8 insertions(+), 42 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
ut the
main thing a mdev should care about is if it is still beween
opne_device() / close_device() - ie the FD is open, there is a SW
IOMMU available, and memory pins can be made.
Still, not for this patch
Reviewed-by: Jason Gunthorpe
Jason
gvt/mmio.c | 4 +--
> drivers/gpu/drm/i915/gvt/mpt.h| 32 ---
> drivers/gpu/drm/i915/gvt/opregion.c | 10 +++-
> drivers/gpu/drm/i915/gvt/scheduler.c | 37 +--
> 10 files changed, 72 insertions(+), 97 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
m/i915/gvt/gvt.h | 3 +-
> drivers/gpu/drm/i915/gvt/hypercall.h | 32 +++
> drivers/gpu/drm/i915/gvt/kvmgt.c | 126 +--
> drivers/gpu/drm/i915/gvt/mpt.h | 20 ++---
> drivers/gpu/drm/i915/gvt/vgpu.c | 6 +-
> 5 files changed, 71 insertio
-
> 2 files changed, 52 insertions(+), 73 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
> drivers/gpu/drm/i915/gvt/kvmgt.c | 288 ++-
> drivers/gpu/drm/i915/gvt/mpt.h | 16 --
> drivers/gpu/drm/i915/gvt/vgpu.c | 8 +-
> 5 files changed, 128 insertions(+), 216 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
nged, 19 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
t/cfg_space.c | 89 ++--
> drivers/gpu/drm/i915/gvt/hypercall.h | 4 --
> drivers/gpu/drm/i915/gvt/mpt.h | 44 --
> 3 files changed, 17 insertions(+), 120 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
drivers/gpu/drm/i915/gvt/gvt.h | 24 --
> drivers/gpu/drm/i915/gvt/hypercall.h | 2 +-
> drivers/gpu/drm/i915/gvt/kvmgt.c | 37 +++-
> drivers/gpu/drm/i915/gvt/mpt.h | 5 ++--
> 5 files changed, 19 insertions(+), 69 deletions
tions(-)
Reviewed-by: Jason Gunthorpe
Jason
pu/drm/i915/gvt/gvt.h | 1 -
> drivers/gpu/drm/i915/gvt/hypercall.h | 6 --
> drivers/gpu/drm/i915/gvt/kvmgt.c | 1 -
> drivers/gpu/drm/i915/gvt/opregion.c | 150 ++-
> 5 files changed, 34 insertions(+), 141 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Tue, Nov 02, 2021 at 08:05:35AM +0100, Christoph Hellwig wrote:
> THIS_MODULE always is reference when a symbol called by it is used, so
> don't bother with the additional reference.
heh, these functions are only called from a module init/exit even
Reviewed-by: Jason Gunthorpe
Jason
drivers/gpu/drm/i915/Makefile | 29 -
> drivers/gpu/drm/i915/gvt/Makefile | 9 -
> drivers/gpu/drm/i915/gvt/trace.h | 2 +-
> 3 files changed, 25 insertions(+), 15 deletions(-)
> delete mode 100644 drivers/gpu/drm/i915/gvt/Makefile
Reviewed-
On Thu, Oct 28, 2021 at 05:14:52PM +0200, Daniel Vetter wrote:
> Hm totally lost this, I'm trying to not be too responsible for mm changes
> since it scares me :-) Plus dropping this very late in the release feels a
> bit risky.
>
> Ok if I stuff this into drm-next instead?
Sure
Jason
On Tue, Oct 12, 2021 at 03:09:00PM +0300, Gal Pressman wrote:
> Hey all,
>
> This is a followup to my previous RFCs [1][2], which now adds a new api
> to the RDMA subsystem that allows drivers to get a pinned dmabuf memory
> region without requiring an implementation of the move_notify callback.
aults")
Reviewed-by: Christian König
Reviewed-by: Thomas Hellström
Acked-by: Daniel Vetter
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c| 2 +-
drivers/g
On Thu, Oct 21, 2021 at 01:40:30PM +0200, Daniel Vetter wrote:
> On Wed, Oct 20, 2021 at 11:09:58AM -0300, Jason Gunthorpe wrote:
> > On Wed, Oct 20, 2021 at 08:34:33AM +0200, Thomas Hellström wrote:
> >
> > > Follow up question: If we resurrect this in the proper way
On Thu, Oct 21, 2021 at 01:41:39PM +0200, Daniel Vetter wrote:
> On Wed, Oct 20, 2021 at 04:37:02PM -0300, Jason Gunthorpe wrote:
> > On Wed, Oct 20, 2021 at 08:41:24AM +0200, Christian König wrote:
> >
> > > > I think the patch subject needs updating to reflect that
On Fri, Oct 01, 2021 at 02:52:41PM -0300, Jason Gunthorpe wrote:
> This addresses Cornelia's remark on the earlier patch that ccw has a
> confusing lifecycle. While it doesn't seem like the original attempt was
> functionally wrong, the result can be made better with a lot of furth
by: Thomas Hellström
Signed-off-by: Jason Gunthorpe
On Wed, Oct 20, 2021 at 08:34:33AM +0200, Thomas Hellström wrote:
> Follow up question: If we resurrect this in the proper way (and in that case
> only for x86_64) is there something we need to pay particular attention to
> WRT the ZONE_DEVICE refcounting fixing you mention above?
Similar to PTE
GUP_fast.
Fixes: 314b6580adc5 ("drm/ttm, drm/vmwgfx: Support huge TTM pagefaults")
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c| 2 +-
drivers/g
On Tue, Oct 19, 2021 at 08:49:29PM +0200, Thomas Hellström wrote:
> Hi,
>
> On 10/19/21 20:21, Jason Gunthorpe wrote:
> > PUD and PMD entries do not have a special bit.
> >
> > get_user_pages_fast() considers any page that passed pmd_huge() as
> > usable:
with vmf_insert_pfn_pud/pmd_prot().
Fixes: 314b6580adc5 ("drm/ttm, drm/vmwgfx: Support huge TTM pagefaults")
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
AFAICT only the vmwgfx driver makes use of this, and I can't
On Tue, Oct 19, 2021 at 04:13:34PM +0100, Joao Martins wrote:
> On 10/19/21 00:06, Jason Gunthorpe wrote:
> > On Mon, Oct 18, 2021 at 12:37:30PM -0700, Dan Williams wrote:
> >
> >>> device-dax uses PUD, along with TTM, they are the only places. I'm not
> >&
On Mon, Oct 18, 2021 at 12:37:30PM -0700, Dan Williams wrote:
> > device-dax uses PUD, along with TTM, they are the only places. I'm not
> > sure TTM is a real place though.
>
> I was setting device-dax aside because it can use Joao's changes to
> get compound-page support.
Ideally, but that
On Sun, Oct 17, 2021 at 11:35:35AM -0700, Dan Williams wrote:
> > DAX is stuffing arrays of 4k pages into the PUD/PMDs. Aligning with
> > THP would make using normal refconting much simpler. I looked at
> > teaching the mm core to deal with page arrays - it is certainly
> > doable, but it is
On Thu, Oct 14, 2021 at 06:37:35PM -0700, Dan Williams wrote:
> On Thu, Oct 14, 2021 at 4:06 PM Jason Gunthorpe wrote:
> >
> > On Thu, Oct 14, 2021 at 12:01:14PM -0700, Dan Williams wrote:
> > > > > Does anyone know why devmap is pte_special anyhow?
> > &g
On Thu, Oct 14, 2021 at 10:45:52PM -0500, Sierra Guiza, Alejandro (Alex) wrote:
>
> On 10/14/2021 3:57 PM, Ralph Campbell wrote:
> >
> > On 10/14/21 11:01 AM, Jason Gunthorpe wrote:
> > > On Thu, Oct 14, 2021 at 10:35:27AM -0700, Ralph Campbell wrote:
> > &g
On Thu, Oct 14, 2021 at 12:01:14PM -0700, Dan Williams wrote:
> > > Does anyone know why devmap is pte_special anyhow?
>
> It does not need to be special as mentioned here:
>
> https://lore.kernel.org/all/CAPcyv4iFeVDVPn6uc=aksyuvkiu3-fk-n16ijvzq3n8ot00...@mail.gmail.com/
I added a remark there
On Thu, Oct 14, 2021 at 10:35:27AM -0700, Ralph Campbell wrote:
> I ran xfstests-dev using the kernel boot option to "fake" a pmem device
> when I first posted this patch. The tests ran OK (or at least the same
> tests passed with and without my patch).
Hmm. I know nothing of xfstests but
On Thu, Oct 14, 2021 at 10:39:28AM -0500, Alex Sierra wrote:
> From: Ralph Campbell
>
> ZONE_DEVICE struct pages have an extra reference count that complicates the
> code for put_page() and several places in the kernel that need to check the
> reference count to see that a page is not being used
s ref count functionality was missing on fuse/dax.c.
> ---
> fs/dax.c| 4 ++--
> fs/ext4/inode.c | 5 +
> fs/fuse/dax.c | 4 +---
> fs/xfs/xfs_file.c | 4 +---
> include/linux/dax.h | 10 ++
> 5 files changed, 15 insertions(+), 12 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Tue, Oct 12, 2021 at 11:39:57AM -0700, Andrew Morton wrote:
> On Tue, 12 Oct 2021 12:12:35 -0500 Alex Sierra wrote:
>
> > This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
> > owned by a device that can be mapped into CPU page tables like
> > MEMORY_DEVICE_GENERIC and can
On Sun, Oct 10, 2021 at 09:55:49AM +0300, Gal Pressman wrote:
> On 07/10/2021 14:40, Jason Gunthorpe wrote:
> > On Thu, Oct 07, 2021 at 01:43:00PM +0300, Gal Pressman wrote:
> >
> >> @@ -1491,26 +1493,29 @@ static int efa_create_pbl(struct efa_de
On Thu, Oct 07, 2021 at 01:43:00PM +0300, Gal Pressman wrote:
> @@ -1491,26 +1493,29 @@ static int efa_create_pbl(struct efa_dev *dev,
> return 0;
> }
>
> -struct ib_mr *efa_reg_mr(struct ib_pd *ibpd, u64 start, u64 length,
> - u64 virt_addr, int access_flags,
> -
vfio_ccw will need it.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio.c | 3 ++-
include/linux/vfio.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 08b27b64f0f935..44adf112e3b5dd 100644
--- a/drivers/vfio/vfio.c
+++ b
is allocated/freed during probe/remove of the
mdev like any other vfio_device struct.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 67 ++---
drivers/s390/cio/vfio_ccw_ops.c | 40 +++--
drivers/s390/cio/vfio_ccw_private.h | 23
Every driver just emits a static string, simply feed it through the ops
and provide a standard sysfs show function.
Signed-off-by: Jason Gunthorpe
---
.../driver-api/vfio-mediated-device.rst | 4 ++-
drivers/gpu/drm/i915/gvt/kvmgt.c | 9 +--
drivers/s390/cio
for their mtypes which is fixed at registration time. The core
provides a standard sysfs attribute to return the available_instances.
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
.../driver-api/vfio-mediated-device.rst | 4 +-
drivers/s390/cio/vfio_ccw_drv.c
mdev_device should only be used in functions assigned to ops callbacks,
interior functions should use the struct vfio_ccw_private instead of
repeatedly trying to get it from the mdev.
Reviewed-by: Christoph Hellwig
Reviewed-by: Cornelia Huck
Reviewed-by: Eric Farman
Signed-off-by: Jason
sch_shutdown() now simply tries to close and
leaves the device BROKEN (though arguably the bus should take care to
quiet down the subchannel HW during shutdown, not the drivers)
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 74 ++-
drivers/s390/cio/vf
Makes the code easier to understand what is memory lifecycle and what is
other stuff.
Reviewed-by: Eric Farman
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 137 ++--
1 file changed, 78 insertions(+), 59 deletions(-)
diff --git a/drivers/s390
ed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 6 ++--
drivers/s390/cio/vfio_ccw_fsm.c | 48 +
drivers/s390/cio/vfio_ccw_ops.c | 16 --
drivers/s390/cio/vfio_ccw_private.h | 2 --
include/linux/mdev.h| 4 ---
5
and
the mdev_device point at the private, and container_of is used to get it
back from the vfio_device.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 21 --
drivers/s390/cio/vfio_ccw_ops.c | 107 +---
drivers/s390/cio/vfio_ccw_private.h | 5
te()
v2: https://lore.kernel.org/r/0-v2-7d3a384024cf+2060-ccw_mdev_...@nvidia.com
- Clean up the lifecycle in ccw with 7 new patches
- Rebase
v1: https://lore.kernel.org/all/7-v2-7667f42c9bad+935-vfio3_...@nvidia.com
Jason Gunthorpe (10):
vfio/ccw: Remove unneeded GFP_DMA
vfio/ccw: Use functions
Since the ccw_io_region was split out of the private the allocation no
longer needs the GFP_DMA. Remove it.
Reported-by: Christoph Hellwig
Fixes: c98e16b2fa12 ("s390/cio: Convert ccw_io_region to pointer")
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 2
On Thu, Sep 30, 2021 at 03:46:35PM +0300, Oded Gabbay wrote:
> After reading the kernel iommu code, I think this is not relevant
> here, and I'll add a comment appropriately but I'll also write it
> here, and please correct me if my understanding is wrong.
>
> The memory behind this specific
On Wed, Sep 29, 2021 at 12:17:35AM +0300, Oded Gabbay wrote:
> On Tue, Sep 28, 2021 at 8:36 PM Jason Gunthorpe wrote:
> >
> > On Sun, Sep 12, 2021 at 07:53:09PM +0300, Oded Gabbay wrote:
> > > From: Tomer Tayar
> > >
> > > Implement the calls to
On Wed, Sep 29, 2021 at 06:27:16PM +, Wang, Zhi A wrote:
> On 9/28/21 3:05 PM, Jason Gunthorpe wrote:
> > On Tue, Sep 28, 2021 at 02:35:06PM +, Wang, Zhi A wrote:
> >
> >> Yes. I was thinking of the possibility of putting off some work later so
> >>
On Sun, Sep 12, 2021 at 07:53:09PM +0300, Oded Gabbay wrote:
> From: Tomer Tayar
>
> Implement the calls to the dma-buf kernel api to create a dma-buf
> object backed by FD.
>
> We block the option to mmap the DMA-BUF object because we don't support
> DIRECT_IO and implicit P2P.
This
On Sun, Sep 12, 2021 at 07:53:08PM +0300, Oded Gabbay wrote:
> /* HL_MEM_OP_* */
> __u32 op;
> - /* HL_MEM_* flags */
> + /* HL_MEM_* flags.
> + * For the HL_MEM_OP_EXPORT_DMABUF_FD opcode, this field holds the
> + * DMA-BUF file/FD flags.
> + */
> __u32
On Tue, Sep 28, 2021 at 02:35:06PM +, Wang, Zhi A wrote:
> Yes. I was thinking of the possibility of putting off some work later so
> that we don't need to make a lot of changes. GVT-g needs to take a
> snapshot of GPU registers as the initial virtual states for other vGPUs,
> which
On Fri, Sep 24, 2021 at 04:45:02PM -0400, Eric Farman wrote:
> On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote:
> > Having a mdev pointer floating about in addition to a struct
> > vfio_device
> > is confusing. It is only used for three things:
> >
> >
On Fri, Sep 24, 2021 at 04:37:43PM -0400, Eric Farman wrote:
> > @@ -528,6 +534,7 @@ static int __init vfio_ccw_sch_init(void)
> >
> > static void __exit vfio_ccw_sch_exit(void)
> > {
> > + mdev_unregister_driver(_ccw_mdev_driver);
>
> Wouldn't it be better to mirror the unwind-init case,
On Mon, Sep 20, 2021 at 08:02:29PM +0200, Cornelia Huck wrote:
> On Thu, Sep 09 2021, Jason Gunthorpe wrote:
>
> > Many of the mdev drivers use a simple counter for keeping track of the
> > available instances. Move this code to the core code and store the counter
> > in
On Mon, Sep 20, 2021 at 02:19:18PM +0200, Cornelia Huck wrote:
> On Thu, Sep 09 2021, Jason Gunthorpe wrote:
>
> > The subchannel should be left in a quiescent state unless the VFIO device
> > FD is opened. When the FD is opened bring the chanel to active and allow
> > th
On Fri, Sep 17, 2021 at 01:59:16PM +0200, Cornelia Huck wrote:
> > ret = cio_cancel_halt_clear(sch, );
> > -
> > if (ret == -EIO) {
> > pr_err("vfio_ccw: could not quiesce subchannel
> > 0.%x.%04x!\n",
> >sch->schid.ssid,
On Thu, Sep 16, 2021 at 02:31:34PM +0200, Daniel Vetter wrote:
> On Wed, Sep 15, 2021 at 10:45:36AM +0300, Oded Gabbay wrote:
> > On Tue, Sep 14, 2021 at 7:12 PM Jason Gunthorpe wrote:
> > >
> > > On Tue, Sep 14, 2021 at 04:18:31PM +0200, Daniel Vetter wrote:
> >
On Tue, Sep 14, 2021 at 05:50:25PM +0200, Cornelia Huck wrote:
> On Fri, Sep 10 2021, Christoph Hellwig wrote:
>
> > On Thu, Sep 09, 2021 at 04:38:41PM -0300, Jason Gunthorpe wrote:
> >> +
> >> + private = kzalloc(sizeof(*private), GFP_KERNEL |
On Tue, Sep 14, 2021 at 04:18:31PM +0200, Daniel Vetter wrote:
> On Sun, Sep 12, 2021 at 07:53:07PM +0300, Oded Gabbay wrote:
> > Hi,
> > Re-sending this patch-set following the release of our user-space TPC
> > compiler and runtime library.
> >
> > I would appreciate a review on this.
>
> I
On Mon, Sep 13, 2021 at 04:31:54PM -0400, Eric Farman wrote:
> > I rebased it and fixed it up here:
> >
> > https://github.com/jgunthorpe/linux/tree/vfio_ccw
> >
> > Can you try again?
>
> That does address the crash, but then why is it processing a BROKEN
> event? Seems problematic.
The
On Mon, Sep 13, 2021 at 01:40:34PM -0400, Eric Farman wrote:
> On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote:
> > This addresses Cornelia's remark on the earlier patch that ccw has a
> > confusing lifecycle. While it doesn't seem like the original attempt
> > was
&
On Fri, Sep 10, 2021 at 01:10:46PM +0100, Christoph Hellwig wrote:
> On Thu, Sep 09, 2021 at 04:38:45PM -0300, Jason Gunthorpe wrote:
> > Every driver just emits a static string, simply feed it through the ops
> > and provide a standard sysfs show function.
>
> Looks sensib
ed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 6 ++--
drivers/s390/cio/vfio_ccw_fsm.c | 48 +
drivers/s390/cio/vfio_ccw_ops.c | 16 --
drivers/s390/cio/vfio_ccw_private.h | 2 --
include/linux/mdev.h| 4 ---
5
is allocated/freed during probe/remove of the
mdev like any other vfio_device struct.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 67 ++---
drivers/s390/cio/vfio_ccw_ops.c | 40 +++--
drivers/s390/cio/vfio_ccw_private.h | 23
and
the mdev_device point at the private, and container_of is used to get it
back from the vfio_device.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 21 --
drivers/s390/cio/vfio_ccw_ops.c | 107 +---
drivers/s390/cio/vfio_ccw_private.h | 5
mdev_device should only be used in functions assigned to ops callbacks,
interior functions should use the struct vfio_ccw_private instead of
repeatedly trying to get it from the mdev.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_ops.c | 37 +
1
Every driver just emits a static string, simply feed it through the ops
and provide a standard sysfs show function.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 9 +
drivers/s390/cio/vfio_ccw_ops.c | 9 +
drivers/s390/crypto/vfio_ap_ops.c | 9
vfio_ccw will need it.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio.c | 3 ++-
include/linux/vfio.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index c3ca33e513c8e9..e78278a0b98a96 100644
--- a/drivers/vfio/vfio.c
+++ b
sch_shutdown() now simply tries to close and
leaves the device BROKEN (though arguably the bus should take care to
quiet down the subchannel HW during shutdown, not the drivers)
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 74 ++--
drivers/s390/cio/vf
for their mtypes which is fixed at registration time. The core
provides a standard sysfs attribute to return the available_instances.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 1 -
drivers/s390/cio/vfio_ccw_ops.c | 26 ++-
drivers/s390/cio
tance" counter, into
the core code and share that logic with many of the other drivers. The
value is kept in the mdev_type memory.
v2:
- Clean up the lifecycle in ccw with 7 new patches
- Rebase
v1: https://lore.kernel.org/all/7-v2-7667f42c9bad+935-vfio3_...@nvidia.com
Jason Gunthorpe (9):
vfi
Makes the code easier to understand what is memory lifecycle and what is
other stuff.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 137 ++--
1 file changed, 78 insertions(+), 59 deletions(-)
diff --git a/drivers/s390/cio/vfio_ccw_drv.c b
On Mon, Aug 30, 2021 at 11:21:00AM +0300, Leon Romanovsky wrote:
> On Tue, Aug 24, 2021 at 05:25:28PM +0300, Maor Gottlieb wrote:
> > From: Maor Gottlieb
> >
> > Changelog:
> > v4:
> > * Unify sg_free_table_entries with __sg_free_table
> > v3:
On Wed, Aug 25, 2021 at 05:14:06PM +0200, Christian König wrote:
> Yeah, that's exactly what I'm talking about by adding cgroup or similar. You
> need a knob to control this.
We have the pinned memory ulimit today.
A pinned memory cgroup might be interesting, but even containrs are
covered
On Wed, Aug 25, 2021 at 03:51:14PM +0200, Christian König wrote:
> Am 25.08.21 um 14:38 schrieb Jason Gunthorpe:
> > On Wed, Aug 25, 2021 at 02:27:08PM +0200, Christian König wrote:
> > > Am 25.08.21 um 14:18 schrieb Jason Gunthorpe:
> > > > On Wed, Aug 25, 2021
On Wed, Aug 25, 2021 at 07:59:27AM +0300, Maor Gottlieb wrote:
>
> On 8/24/2021 10:12 PM, Jason Gunthorpe wrote:
> > On Tue, Aug 24, 2021 at 05:25:30PM +0300, Maor Gottlieb wrote:
> > > @@ -514,11 +531,13 @@ struct scatterlist
> > > *sg_alloc_append_table_f
On Wed, Aug 25, 2021 at 08:17:51AM +0200, Christian König wrote:
> The only real option where you could do P2P with buffer pinning are those
> compute boards where we know that everything is always accessible to
> everybody and we will never need to migrate anything. But even then you want
> some
On Wed, Aug 25, 2021 at 02:27:08PM +0200, Christian König wrote:
> Am 25.08.21 um 14:18 schrieb Jason Gunthorpe:
> > On Wed, Aug 25, 2021 at 08:17:51AM +0200, Christian König wrote:
> >
> > > The only real option where you could do P2P with buffer pinning are those
>
On Wed, Aug 25, 2021 at 05:15:52AM +1000, Dave Airlie wrote:
> On Wed, 25 Aug 2021 at 03:36, John Hubbard wrote:
> >
> > On 8/24/21 10:32 AM, Jason Gunthorpe wrote:
> > ...
> > >>> And yes at least for the amdgpu driver we migrate the memory to host
> >
On Tue, Aug 24, 2021 at 05:25:30PM +0300, Maor Gottlieb wrote:
> @@ -514,11 +531,13 @@ struct scatterlist
> *sg_alloc_append_table_from_pages(struct sg_table *sgt,
> offset = 0;
> cur_page = j;
> }
> - sgt->nents += added_nents;
> + sgt_append->sgt.nents
501 - 600 of 1605 matches
Mail list logo
