On Wed, Apr 20, 2022 at 04:34:47PM +, Wang, Zhi A wrote:
> Hi folks:
>
> Here is the PR of gvt-next. Thanks so much for the patience.
>
> Mostly it includes the patch bundle of GVT-g re-factor patches for adapting
> the GVT-g with the
> new MDEV interfaces:
>
> - Separating the MMIO table
On Mon, Apr 18, 2022 at 11:25:15AM -0400, Jason J. Herne wrote:
> On 4/12/22 11:53, Jason Gunthorpe wrote:
> > Every caller has a readily available vfio_device pointer, use that instead
> > of passing in a generic struct device. The struct vfio_device already
> > contains
On Mon, Apr 18, 2022 at 11:28:30AM -0400, Tony Krowiak wrote:
> > diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> > index a4555014bd1e72..8a5c46aa2bef61 100644
> > +++ b/drivers/vfio/vfio.c
> > @@ -2484,19 +2484,15 @@ static int vfio_unregister_group_notifier(struct
> > vfio_group
On Fri, Apr 15, 2022 at 02:32:08AM +, Tian, Kevin wrote:
> While it's a welcomed fix is it actually related to this series? The point
> of this patch is that those functions are called when container_users
> is non-zero. This is true even without this fix given container_users
> is
On Thu, Apr 14, 2022 at 02:25:36PM +, Wang, Zhi A wrote:
> > So drop the '[DONT PULL]' commit and send a PR to the next DRM tree -
> > when that is confirmed send the same PR to vfio,
>
> I updated the branch again, but I am confused. What is the purpose of sending
> the PR to next DRM tree?
On Thu, Apr 14, 2022 at 09:51:49AM -0400, Matthew Rosato wrote:
> On 4/12/22 11:53 AM, Jason Gunthorpe wrote:
> > When the open_device() op is called the container_users is incremented and
> > held incremented until close_device(). Thus, so long as drivers call
>
On Thu, Apr 14, 2022 at 04:40:11PM +0300, Jani Nikula wrote:
> >> >> git clone https://github.com/intel/gvt-linux -b for-christoph
> >> >
> >> > There are alot of extra commits on there - is it possible to base this
> >> > straight on rc1 not on some kind of existing DRM tree?
> >> >
> >> > Why
On Thu, Apr 14, 2022 at 01:39:11PM +, Wang, Zhi A wrote:
> On 4/14/22 1:34 PM, Jason Gunthorpe wrote:
> > On Thu, Apr 14, 2022 at 12:20:42PM +, Wang, Zhi A wrote:
> >> On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
> >>> On Wed, Apr 13, 2022 at 11:13:06PM +
On Thu, Apr 14, 2022 at 12:20:42PM +, Wang, Zhi A wrote:
> On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
> > On Wed, Apr 13, 2022 at 11:13:06PM +, Wang, Zhi A wrote:
> >> Hi folks:
> >>
> >> Thanks so much for the efforts. I prepared a branch which co
On Wed, Apr 13, 2022 at 11:13:06PM +, Wang, Zhi A wrote:
> Hi folks:
>
> Thanks so much for the efforts. I prepared a branch which contains all our
> patches.The aim of the branch is for the VFIO maintainers to pull the whole
> bunch easily after the drm-intel-next got merged through drm
On Wed, Apr 13, 2022 at 09:08:40PM +, Wang, Zhi A wrote:
> On 4/13/22 8:04 PM, Jason Gunthorpe wrote:
> > On Wed, Apr 13, 2022 at 07:17:52PM +, Wang, Zhi A wrote:
> >> On 4/13/22 5:37 PM, Jason Gunthorpe wrote:
> >>> On Wed, Apr 13, 2022 at 06:29:46PM
On Wed, Apr 13, 2022 at 07:17:52PM +, Wang, Zhi A wrote:
> On 4/13/22 5:37 PM, Jason Gunthorpe wrote:
> > On Wed, Apr 13, 2022 at 06:29:46PM +0200, Christoph Hellwig wrote:
> >> On Wed, Apr 13, 2022 at 01:18:14PM -0300, Jason Gunthorpe wrote:
> >>> Yeah,
On Wed, Apr 13, 2022 at 06:29:46PM +0200, Christoph Hellwig wrote:
> On Wed, Apr 13, 2022 at 01:18:14PM -0300, Jason Gunthorpe wrote:
> > Yeah, I was thinking about that too, but on the other hand I think it
> > is completely wrong that gvt requires kvm at all. A vfio_device is n
On Wed, Apr 13, 2022 at 06:06:01PM +0200, Christoph Hellwig wrote:
> On Wed, Apr 13, 2022 at 08:39:52AM -0300, Jason Gunthorpe wrote:
> > I already looked into that for a while, it is a real mess too because
> > of how the notifiers are used by the current drivers, eg gvt assumes
&
On Wed, Apr 13, 2022 at 02:26:23PM +, Wang, Zhi A wrote:
> On 4/13/22 1:43 PM, Jason Gunthorpe wrote:
> > On Wed, Apr 13, 2022 at 01:39:35PM +, Wang, Zhi A wrote:
> >
> >> It seems Jani's makefile clean patch has already included this one, I can
> >
On Wed, Apr 13, 2022 at 08:11:05AM +0200, Christoph Hellwig wrote:
> On Tue, Apr 12, 2022 at 12:53:36PM -0300, Jason Gunthorpe wrote:
> > + if (WARN_ON(!READ_ONCE(vdev->open_count)))
> > + return -EINVAL;
>
> I think all the WARN_ON()s in this patch
On Wed, Apr 13, 2022 at 01:39:35PM +, Wang, Zhi A wrote:
> It seems Jani's makefile clean patch has already included this one, I can
> just simply drop this one so that Christoph won't need to re-send everything.
>
> For the branch to move on, I am merging the patches and will re-generate
On Wed, Apr 13, 2022 at 08:01:10AM +0200, Christoph Hellwig wrote:
> On Tue, Apr 12, 2022 at 12:53:31PM -0300, Jason Gunthorpe wrote:
> > Use the existing vfio_device versions of vfio_(un)pin_pages(). There is no
> > reason to use a group interface here, kvmgt has easy access to a
On Wed, Apr 13, 2022 at 08:00:08AM +0200, Christoph Hellwig wrote:
> This looks good execept the extern nitpick:
>
> Reviewed-by: Christoph Hellwig
>
> However I'd move this before the previous patch. More of the explanation
> there.
Yes, that looks good, done
Thanks,
Jason
On Wed, Apr 13, 2022 at 07:57:17AM +0200, Christoph Hellwig wrote:
> > - extern int vfio_pin_pages(struct device *dev, unsigned long *user_pfn,
> > + extern int vfio_pin_pages(struct vfio_device *vdev, unsigned long
> > *user_pfn,
> > int npage, int prot,
On Wed, Apr 13, 2022 at 07:55:24AM +0200, Christoph Hellwig wrote:
> On Tue, Apr 12, 2022 at 12:53:28PM -0300, Jason Gunthorpe wrote:
> > All callers have a struct vfio_device trivially available, pass it in
> > directly and avoid calling the expensive vfio_group_get_from_dev(
this cycle.
I have a followup series that needs this.
This is also part of the iommufd work - moving the driver facing interface
to vfio_device provides a much cleaner path to integrate with iommufd.
Signed-off-by: Jason Gunthorpe
Jason Gunthorpe (9):
vfio: Make vfio_(un)register_notifier accept
Now that callers have been updated to use the vfio_device APIs the driver
facing group interface is no longer used, delete it:
- vfio_group_get_external_user_from_dev()
- vfio_group_pin_pages()
- vfio_group_unpin_pages()
- vfio_group_iommu_domain()
Signed-off-by: Jason Gunthorpe
---
drivers
Use the existing vfio_device versions of vfio_(un)pin_pages(). There is no
reason to use a group interface here, kvmgt has easy access to a
vfio_device.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git
try_module_get() must be undone if kvmgt_guest_init() fails or we leak the
module reference count on the failure path since the close_device op is
never called in this case.
Fixes: 9bdb073464d6 ("drm/i915/gvt: Change KVMGT as self load module")
Signed-off-by: Jason Gunthorpe
---
drive
between
open_device()/close_device():
vfio_pin_pages()
vfio_unpin_pages()
vfio_dma_rw()
vfio_register_notifier()
vfio_unregister_notifier()
So eliminate the calls to vfio_group_add_container_user() and add a simple
WARN_ON to detect mis-use by drivers.
Signed-off-by: Jason Gunthorpe
The next patch wants the vfio_device instead. There is no reason to store
a pointer here since we can container_of back to the vfio_device.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_cp.c | 44 +++--
drivers/s390/cio/vfio_ccw_cp.h | 4
Nothing references this struct member any more, delete it completely.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
Every caller has a readily available vfio_device pointer, use that instead
of passing in a generic struct device. The struct vfio_device already
contains the group we need so this avoids complexity, extra refcountings,
and a confusing lifecycle model.
Signed-off-by: Jason Gunthorpe
---
drivers
Every caller has a readily available vfio_device pointer, use that instead
of passing in a generic struct device. The struct vfio_device already
contains the group we need so this avoids complexity, extra refcountings,
and a confusing lifecycle model.
Signed-off-by: Jason Gunthorpe
.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 15 +--
drivers/s390/cio/vfio_ccw_ops.c | 7 +++
drivers/s390/crypto/vfio_ap_ops.c | 14 +++---
drivers/vfio/mdev/vfio_mdev.c | 12
drivers/vfio/vfio.c | 25
es changed, 193 insertions(+), 154 deletions(-)
There is a few things going on in here, I looked a few times and
didn't spot anything..
Reviewed-by: Jason Gunthorpe
Jason
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
ons(-)
It is nice
Reviewed-by: Jason Gunthorpe
> @@ -847,14 +873,37 @@ static int intel_vgpu_open_device(struct mdev_device
> *mdev)
> goto undo_group;
> }
>
> - ret = kvmgt_guest_init(mdev);
> - if (ret)
> + ret = -EEXIST;
> + if (vg
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
reate succeeded for mdev: %s\n",
> - dev_name(mdev_dev(mdev)));
nit: the debug print has the wrong function name now
Rest looks OK
Reviewed-by: Jason Gunthorpe
Jason
_work' callpath is buggy, for many reasons, but not
for this series.
Reviewed-by: Jason Gunthorpe
> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
> b/drivers/gpu/drm/i915/gvt/dmabuf.c
> index 90443306a9ad4..01e54b45c5c1b 100644
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
> @
(-)
> delete mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h
> delete mode 100644 drivers/gpu/drm/i915/gvt/mpt.h
That gvt_vgpu_type_groups stuff is pretty wonky, but it can be left
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
/drm/i915/gvt/kvmgt.c | 22
> drivers/gpu/drm/i915/gvt/mpt.h | 30
> 4 files changed, 7 insertions(+), 59 deletions(-)
Reviewed-by: Jason Gunthorpe
Had to look ahead in the series to see that the
vfio_device_get_from_dev() was removed too :)
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
rtions(+), 116 deletions(-)
Yay typesafety!
Reviewed-by: Jason Gunthorpe
Jason
-
> 2 files changed, 52 insertions(+), 73 deletions(-)
Reviewed-by: Jason Gunthorpe
> @@ -236,6 +239,11 @@ struct intel_vgpu {
> atomic_t released;
> struct vfio_device *vfio_device;
> struct vfio_group *vfio_group;
> +
> + struct kvm_page_tra
> 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(-)
Happy to see it
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
On Mon, Apr 11, 2022 at 04:13:36PM +0200, Christoph Hellwig wrote:
> Remove these pointless indirect alls by just calling the only instance
'alls' -> 'calls'
Reviewed-by: Jason Gunthorpe
Jason
; + gvt/sched_policy.o \
> + gvt/mmio_context.o \
> + gvt/cmd_parser.o \
> + gvt/debugfs.o \
> + gvt/fb_decoder.o \
> + gvt/dmabuf.o \
> + gvt/page_track.o
Up to you but I usually sort these lists
Reviewed-by: Jason Gunthorpe
Jason
just do away with the include path manipulation.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/Makefile | 1 -
> drivers/gpu/drm/i915/gvt/trace.h | 2 +-
> 2 files changed, 1 insertion(+), 2 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
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 Fri, Apr 01, 2022 at 04:08:35PM -0400, Felix Kuehling wrote:
> > In general I find the vm_normal_lru_page vs vm_normal_page
> > API highly confusing. An explicit check for zone device pages
> > in the dozen or so spots that care has a much better documentation
> > value, especially if
ig
> > Reviewed-by: Daniel Vetter
> > Cc: Jason Gunthorpe
>
> Jason, can you ack this for merging through drm trees please?
Sure, it looks trivial, but I didn't see the whole series:
Acked-by: Jason Gunthorpe
Jason
On Thu, Mar 17, 2022 at 09:13:50AM +0100, David Hildenbrand wrote:
> On 17.03.22 03:54, Alistair Popple wrote:
> > Felix Kuehling writes:
> >
> >> On 2022-03-11 04:16, David Hildenbrand wrote:
> >>> On 10.03.22 18:26, Alex Sierra wrote:
> DEVICE_COHERENT pages introduce a subtle distinction
On Fri, Feb 18, 2022 at 02:20:45PM -0500, Felix Kuehling wrote:
> Am 2022-02-17 um 19:19 schrieb Jason Gunthorpe:
> > On Thu, Feb 17, 2022 at 04:12:20PM -0500, Felix Kuehling wrote:
> >
> > > I'm thinking of a more theoretical approach: Instead of auditing all
> >
On Fri, Feb 18, 2022 at 03:57:27PM +0800, David Gow wrote:
> There are a number of Kconfig options which break compilation under UML with
> allyesconfig. As kunit_tool's --alltests option is based on allyesconfig and
> UML, we need to update the list of broken options to make --alltests build
>
On Thu, Feb 17, 2022 at 04:12:20PM -0500, Felix Kuehling wrote:
> I'm thinking of a more theoretical approach: Instead of auditing all users,
> I'd ask, what are the invariants that a vm_normal_page should have. Then
> check, whether our DEVICE_COHERENT pages satisfy them. But maybe the concept
>
On Wed, Feb 16, 2022 at 11:56:51AM -0500, Felix Kuehling wrote:
> In the case of DEVICE_COHERENT memory, the pfns correspond to real physical
> memory addresses. I don't think they have those PFN_DEV|PFN_MAP bits set.
So do DAX pages. The PTE flag does several things. As this would be
the first
On Wed, Feb 16, 2022 at 09:31:03AM +0100, David Hildenbrand wrote:
> On 16.02.22 03:36, Alistair Popple wrote:
> > On Wednesday, 16 February 2022 1:03:57 PM AEDT Jason Gunthorpe wrote:
> >> On Wed, Feb 16, 2022 at 12:23:44PM +1100, Alistair Popple wrote:
> >>
>
On Wed, Feb 16, 2022 at 12:23:44PM +1100, Alistair Popple wrote:
> Device private and device coherent pages are not marked with pte_devmap and
> they
> are backed by a struct page. The only way of inserting them is via
> migrate_vma.
> The refcount is decremented in zap_pte_range() on munmap()
On Tue, Feb 15, 2022 at 05:49:07PM -0500, Felix Kuehling wrote:
> > Userspace does
> > 1) mmap(MAP_PRIVATE) to allocate anon memory
> > 2) something to trigger migration to install a ZONE_DEVICE page
> > 3) munmap()
> >
> > Who decrements the refcout on the munmap?
> >
> > When a
On Tue, Feb 15, 2022 at 04:35:56PM -0500, Felix Kuehling wrote:
>
> On 2022-02-15 14:41, Jason Gunthorpe wrote:
> > On Tue, Feb 15, 2022 at 07:32:09PM +0100, Christoph Hellwig wrote:
> > > On Tue, Feb 15, 2022 at 10:45:24AM -0400, Jason Gunthorpe wrote:
> > > >
On Tue, Feb 15, 2022 at 07:32:09PM +0100, Christoph Hellwig wrote:
> On Tue, Feb 15, 2022 at 10:45:24AM -0400, Jason Gunthorpe wrote:
> > > Do you know if DEVICE_GENERIC pages would end up as PageAnon()? My
> > > assumption was that they would be part of a special mapping.
>
On Tue, Feb 15, 2022 at 01:16:43PM +0100, David Hildenbrand wrote:
> > fact, the first version of our patches attempted to add migration
> > support to DEVICE_GENERIC. But we were convinced to create a new
> > ZONE_DEVICE page type for our use case instead.
>
> Do you know if DEVICE_GENERIC
On Fri, Feb 11, 2022 at 05:49:08PM +0100, David Hildenbrand wrote:
> On 11.02.22 17:45, Jason Gunthorpe wrote:
> > On Fri, Feb 11, 2022 at 05:15:25PM +0100, David Hildenbrand wrote:
> >
> >> ... I'm pretty sure we cannot FOLL_PIN DEVICE_PRIVATE pages
> >
>
On Fri, Feb 11, 2022 at 05:15:25PM +0100, David Hildenbrand wrote:
> ... I'm pretty sure we cannot FOLL_PIN DEVICE_PRIVATE pages
Currently the only way to get a DEVICE_PRIVATE page out of the page
tables is via hmm_range_fault() and that doesn't manipulate any ref
counts.
Jason
On Wed, Feb 09, 2022 at 02:53:51PM +0100, Christoph Hellwig wrote:
> On Wed, Feb 09, 2022 at 08:29:56AM -0400, Jason Gunthorpe wrote:
> > It is nice, but the other series are still impacted by the fsdax mess
> > - they still stuff pages into ptes without proper refcounts and ha
On Wed, Feb 09, 2022 at 07:23:45AM +0100, Christoph Hellwig wrote:
> On Tue, Feb 08, 2022 at 07:30:11PM -0800, Dan Williams wrote:
> > Interesting. I had expected that to really fix the refcount problem
> > that fs/dax.c would need to start taking real page references as pages
> > were added to a
fs/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
Makes sense, but leaves me wonder why a kconfig randomizer didn't hit
this.. Or maybe it means some of the function stubs on !ZONE_DEVICE
are unnecessary now..
Reviewed-by: Jason Gunthorpe
Jason
> include/linux/mm.h | 20
> lib/test_hmm.c | 1 +
> mm/memremap.c | 6 +-
> 14 files changed, 34 insertions(+), 22 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
de/linux/mm.h | 34 ++
> mm/memremap.c | 20 +---
> mm/swap.c | 10 +-
> 3 files changed, 20 insertions(+), 44 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
-
> mm/memremap.c | 21 +
> mm/swap.c | 23 ---
> 3 files changed, 21 insertions(+), 24 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Mon, Feb 07, 2022 at 07:32:43AM +0100, Christoph Hellwig wrote:
> __KERNEL__ ifdefs don't make sense outside of include/uapi/.
>
> Signed-off-by: Christoph Hellwig
> ---
> include/linux/mm.h | 4
> 1 file changed, 4 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
eletions(-)
Reviewed-by: Jason Gunthorpe
Jason
-
> mm/memremap.c| 57
> mm/migrate.c | 6 ---
> mm/swap.c| 16 ++-
> 13 files changed, 36 insertions(+), 83 deletions(-)
It looks like a good next step to me
Reviewed
1 +
> drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 +
> include/linux/hmm.h | 9 ++---
> lib/test_hmm.c | 2 ++
> 4 files changed, 6 insertions(+), 7 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Wed, Feb 02, 2022 at 03:57:50PM +0100, Christoph Hellwig wrote:
> On Thu, Jan 27, 2022 at 02:32:58PM -0800, Andrew Morton wrote:
> > On Wed, 26 Jan 2022 21:09:39 -0600 Alex Sierra wrote:
> >
> > > This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
> > > owned by a device
On Mon, Jan 24, 2022 at 12:12:12PM +0200, zhi.wang.li...@gmail.com wrote:
> Hi Christoph and Jason:
>
> Have been talking with Raj. I am going to work on this series this week.
Thanks!
Jason
On Thu, Jan 20, 2022 at 03:03:40PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 12, 2022 at 06:37:03PM +, Matthew Wilcox wrote:
> > But let's go further than that (which only brings us to 32 bytes per
> > range). For the systems you care about which use an identity mapping,
> > and have
On Fri, Jan 14, 2022 at 11:30:36AM -0500, Eric Farman wrote:
> On Fri, 2022-01-14 at 20:28 +0800, Liu Yi L wrote:
> > Hi Eric,
> >
> > Hope you are back from new year holiday.:-) Have you got chane to
> > consider
> > this patch?
>
> Hi Yi Liu,
>
> It's coming up the list, but it's not there
On Wed, Jan 12, 2022 at 06:37:03PM +, Matthew Wilcox wrote:
> On Tue, Jan 11, 2022 at 06:53:06PM -0400, Jason Gunthorpe wrote:
> > IOMMU is not common in those cases, it is slow.
> >
> > So you end up with 16 bytes per entry then another 24 bytes in the
> > enti
On Tue, Jan 11, 2022 at 03:57:07PM -0700, Logan Gunthorpe wrote:
>
>
> On 2022-01-11 3:53 p.m., Jason Gunthorpe wrote:
> > I just want to share the whole API that will have to exist to
> > reasonably support this flexible array of intervals data structure..
>
> Is t
On Tue, Jan 11, 2022 at 03:09:13PM -0700, Logan Gunthorpe wrote:
> Either that, or we need a wrapper that allocates an appropriately
> sized SGL to pass to any dma_map implementation that doesn't support
> the new structures.
This is what I think we should do. If we start with RDMA then we can
On Tue, Jan 11, 2022 at 09:25:40PM +, Matthew Wilcox wrote:
> > I don't need the sgt at all. I just need another list of physical
> > addresses for DMA. I see no issue with a phsr_list storing either CPU
> > Physical Address or DMA Physical Addresses, same data structure.
>
> There's a
On Tue, Jan 11, 2022 at 10:05:40AM +0100, Daniel Vetter wrote:
> If we go with page size I think hardcoding a PHYS_PAGE_SIZE KB(4)
> would make sense, because thanks to x86 that's pretty much the lowest
> common denominator that all hw (I know of at least) supports. Not
> having to fiddle with
On Tue, Jan 11, 2022 at 06:33:57PM +, Matthew Wilcox wrote:
> > Then we are we using get_user_phyr() at all if we are just storing it
> > in a sg?
>
> I did consider just implementing get_user_sg() (actually 4 years ago),
> but that cements the use of sg as both an input and output data
On Tue, Jan 11, 2022 at 02:01:17PM +, Matthew Wilcox wrote:
> On Tue, Jan 11, 2022 at 12:17:18AM -0800, John Hubbard wrote:
> > Zooming in on the pinning aspect for a moment: last time I attempted to
> > convert O_DIRECT callers from gup to pup, I recall wanting very much to
> > record, in
On Tue, Jan 11, 2022 at 04:32:56AM +, Matthew Wilcox wrote:
> On Mon, Jan 10, 2022 at 08:41:26PM -0400, Jason Gunthorpe wrote:
> > On Mon, Jan 10, 2022 at 07:34:49PM +, Matthew Wilcox wrote:
> >
> > > Finally, it may be possible to stop using scatterlist to
On Mon, Jan 10, 2022 at 07:34:49PM +, Matthew Wilcox wrote:
> Finally, it may be possible to stop using scatterlist to describe the
> input to the DMA-mapping operation. We may be able to get struct
> scatterlist down to just dma_address and dma_length, with chaining
> handled through an
On Fri, Dec 10, 2021 at 01:47:37PM +0100, Christian König wrote:
> Am 10.12.21 um 13:42 schrieb Jason Gunthorpe:
> > On Fri, Dec 10, 2021 at 08:29:24PM +0900, Shunsuke Mie wrote:
> > > Hi Jason,
> > > Thank you for replying.
> > >
> > > 2021年12月8日(水)
On Fri, Dec 10, 2021 at 08:29:24PM +0900, Shunsuke Mie wrote:
> Hi Jason,
> Thank you for replying.
>
> 2021年12月8日(水) 2:14 Jason Gunthorpe :
> >
> > On Fri, Dec 03, 2021 at 12:51:44PM +0900, Shunsuke Mie wrote:
> > > Hi maintainers,
> > >
>
On Thu, Dec 09, 2021 at 12:45:24PM +1100, Alistair Popple wrote:
> On Thursday, 9 December 2021 12:53:45 AM AEDT Jason Gunthorpe wrote:
> > > I think a similar problem exists for device private fault handling as
> > > well and
> > > it has been on my list of thin
401 - 500 of 1605 matches
Mail list logo
