On Thu, Mar 30, 2023 at 2:22 AM Sean Christopherson wrote:
>
> +David
>
> On Wed, Mar 29, 2023, Paolo Bonzini wrote:
> > On 3/29/23 18:43, Christian K�nig wrote:
> > > >
> > > >
> > > > 3) other uses of kmap() must switch to MMU-notifier protection.
> > >
> > > I would rather suggest to return t
Implement virtgpu specific map_dma_buf callback to support mapping
exported vram object dma-bufs. The dma-buf callback is used directly, as
vram objects don't have backing pages and thus can't implement the
drm_gem_object_funcs.get_sg_table callback.
Signed-off-by: David Stevens
--
Blob resources without the cross device flag don't have a uuid to share
with other virtio devices. When exporting such blobs, set uuid_state to
STATE_ERR so that virtgpu_virtio_get_uuid doesn't hang.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_prime.c | 2 ++
1 fi
Implement virtgpu specific map_dma_buf callback to support mapping
exported vram object dma-bufs. The dma-buf callback is used directly, as
vram objects don't have backing pages and thus can't implement the
drm_gem_object_funcs.get_sg_table callback.
Signed-off-by: David Stevens
---
d
From: David Stevens
Remove two warnings that require ref counts for pages to be non-zero, as
mapped pfns from follow_pfn may not have an initialized ref count.
Signed-off-by: David Stevens
---
arch/x86/kvm/mmu/mmu.c | 7 ---
virt/kvm/kvm_main.c| 2 +-
2 files changed, 1 insertion
From: David Stevens
Covert usages of the deprecated gfn_to_pfn functions to the new
gfn_to_pfn_page functions.
Signed-off-by: David Stevens
---
arch/arm64/kvm/mmu.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch
From: David Stevens
Covert usages of the deprecated gfn_to_pfn functions to the new
gfn_to_pfn_page functions.
Signed-off-by: David Stevens
---
arch/x86/kvm/mmu/mmu.c | 43 -
arch/x86/kvm/mmu/mmu_internal.h | 3 ++-
arch/x86/kvm/mmu/paging_tmpl.h
From: David Stevens
Introduce new gfn_to_pfn_page functions that parallel existing
gfn_to_pfn functions. The new functions are identical except they take
an additional out parameter that is used to return the struct page if
the hva was resolved by gup. This allows callers to differentiate the
From: Nicholas Piggin
It's possible to create a region which maps valid but non-refcounted
pages (e.g., tail pages of non-compound higher order allocations). These
host pages can then be returned by gfn_to_page, gfn_to_pfn, etc., family
of APIs, which take a reference to the page, which takes it
ges to mmu_audit.c
- Include Nicholas Piggin's patch to avoid corrupting refcount in the
follow_pte case, and use it in depreciated gfn_to_pfn functions.
- Rebase on kvm/next
David Stevens (4):
KVM: mmu: introduce new gfn_to_pfn_page functions
KVM: x86/mmu: use gfn_to_pfn_page
KVM: a
Please ignore this last patch. It was put together as an afterthought
and wasn't properly tested.
-David
On Thu, Jun 24, 2021 at 12:59 PM David Stevens wrote:
>
> Return struct page instead of pfn from gfn_to_mfn. This function is only
> used to determine if the page is a transp
reference on the page returned by
gfn_to_pfn.
Signed-off-by: David Stevens
---
drivers/gpu/drm/i915/gvt/gtt.c | 12
drivers/gpu/drm/i915/gvt/hypercall.h | 3 ++-
drivers/gpu/drm/i915/gvt/kvmgt.c | 12
drivers/gpu/drm/i915/gvt/mpt.h | 8
4 files
From: David Stevens
Remove two warnings that require ref counts for pages to be non-zero, as
mapped pfns from follow_pfn may not have an initialized ref count.
Signed-off-by: David Stevens
---
arch/x86/kvm/mmu/mmu.c | 7 ---
virt/kvm/kvm_main.c| 2 +-
2 files changed, 1 insertion
From: David Stevens
Avoid converting pfns returned by follow_fault_pfn to struct pages to
transiently take a reference. The reference was originally taken to
match the reference taken by gup. However, pfns returned by
follow_fault_pfn may not have a struct page set up for reference
counting
From: David Stevens
Avoid converting pfns returned by follow_fault_pfn to struct pages to
transiently take a reference. The reference was originally taken to
match the reference taken by gup. However, pfns returned by
follow_fault_pfn may not have a struct page set up for reference
counting
From: David Stevens
Return a struct kvm_pfn_page containing both a pfn and an optional
struct page from the gfn_to_pfn family of functions. This differentiates
the gup and follow_fault_pfn cases, which allows callers that only need
a pfn to avoid touching the page struct in the latter case. For
From: David Stevens
Signed-off-by: David Stevens
---
arch/x86/kvm/mmu/mmu_audit.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kvm/mmu/mmu_audit.c b/arch/x86/kvm/mmu/mmu_audit.c
index cedc17b2f60e..97ff184084b4 100644
--- a/arch/x86/kvm/mmu/mmu_audit.c
+++ b/arch/x86/kvm/mmu
and arm64.
David Stevens (6):
KVM: x86/mmu: release audited pfns
KVM: mmu: also return page from gfn_to_pfn
KVM: x86/mmu: avoid struct page in MMU
KVM: arm64/mmu: avoid struct page in MMU
KVM: mmu: remove over-aggressive warnings
drm/i915/gvt: use gfn_to_pfn's page instead of pfn
Pushing to drm-misc-next works for me. Thanks for the quick responses.
-David
On Thu, Apr 8, 2021 at 6:56 PM Christian König wrote:
>
> Am 08.04.21 um 11:54 schrieb David Stevens:
> > From: David Stevens
> >
> > Allocate a new private stub fence in drm_syncobj_assign_
From: David Stevens
Allocate a new private stub fence in drm_syncobj_assign_null_handle,
instead of using a static stub fence.
When userspace creates a fence with DRM_SYNCOBJ_CREATE_SIGNALED or when
userspace signals a fence via DRM_IOCTL_SYNCOBJ_SIGNAL, the timestamp
obtained when the fence is
From: David Stevens
Allocate a new private stub fence in drm_syncobj_assign_null_handle,
instead of using a static stub fence.
When userspace creates a fence with DRM_SYNCOBJ_CREATE_SIGNALED or when
userspace signals a fence via DRM_IOCTL_SYNCOBJ_SIGNAL, the timestamp
obtained when the fence is
Sorry, I forgot to checkpatch this, I'll resend it momentarily.
-David
On Thu, Apr 8, 2021 at 6:34 PM David Stevens wrote:
>
> From: David Stevens
>
> Allocate a new private stub fence in drm_syncobj_assign_null_handle,
> instead of using a static stub fence.
>
> When
From: David Stevens
Allocate a new private stub fence in drm_syncobj_assign_null_handle,
instead of using a static stub fence.
When userspace creates a fence with DRM_SYNCOBJ_CREATE_SIGNALED or when
userspace signals a fence via DRM_IOCTL_SYNCOBJ_SIGNAL, the timestamp
obtained when the fence is
On Thu, Apr 8, 2021 at 4:03 PM Christian König wrote:
>
> Am 08.04.21 um 06:59 schrieb David Stevens:
> > From: David Stevens
> >
> > This reverts commit 86bbd89d5da66fe760049ad3f04adc407ec0c4d6.
> >
> > Using the singleton stub fence in drm_syncobj_assign_nul
From: David Stevens
This reverts commit 86bbd89d5da66fe760049ad3f04adc407ec0c4d6.
Using the singleton stub fence in drm_syncobj_assign_null_handle means
that all syncobjs created in an already signaled state or any syncobjs
signaled by userspace will reference the singleton fence when exported
On Wed, Jan 13, 2021 at 5:58 PM Christian König
wrote:
>
> Am 13.01.21 um 09:47 schrieb David Stevens:
> > Compound page metadata is necessary for page reference counting to work
> > properly on pages besides the head page. Without it, put_page
> > corresponding to the l
Compound page metadata is necessary for page reference counting to work
properly on pages besides the head page. Without it, put_page
corresponding to the last outstanding get_page call on a tail page will
end up freeing that page, even if the bo still references the page.
Signed-off-by: David
Reviewed-by: David Stevens
On Tue, Oct 13, 2020 at 2:18 AM Andy Shevchenko
wrote:
>
> There is import_uuid() function which imports u8 array to the uuid_t.
> Use it instead of open coding variant.
>
> This allows to hide the uuid_t internals.
>
> Signed-off-by: Andy Shevche
Reported-by: kernel test robot
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/Kconfig | 1 +
drivers/virtio/Kconfig | 7 +++
drivers/virtio/Makefile | 3 ++-
drivers/virtio/virtio_dma_buf.c | 3 +++
4 files changed, 13 insertions(+), 1 deletion(-)
diff --git a
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 +
drivers/gpu/drm/virtio/virtgpu_drv.h
This change adds a new flavor of dma-bufs that can be used by virtio
drivers to share exported objects. A virtio dma-buf can be queried by
virtio drivers to obtain the UUID which identifies the underlying
exported object.
Signed-off-by: David Stevens
---
drivers/virtio/Makefile | 2
://markmail.org/thread/p5d3k566srtdtute
[3] https://markmail.org/thread/j4xlqaaim266qpks
v5 -> v6 changes:
- Fix >80 character comment
David Stevens (3):
virtio: add dma-buf support for exported objects
virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature
drm/virtio: Support virtgpu ex
On Mon, Aug 17, 2020 at 4:12 AM Gerd Hoffmann wrote:
>
> On Mon, Aug 17, 2020 at 12:50:08PM +0200, Gerd Hoffmann wrote:
> > On Tue, Jun 23, 2020 at 10:31:28AM +0900, David Stevens wrote:
> > > Unless there are any remaining objections to these patches, what are
> &g
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 +
drivers/gpu/drm/virtio/virtgpu_drv.h
> Hmm, checkpatch still complains, full log below.
>
> IIRC "dim checkpatch" runs scripts/checkpatch.pl with --strict
> so it is a bit more picky ...
Ah, I didn't know --strict was being used. I'll send an update
momentarily. Sorry for the churn.
> -:250: CHECK:PREFER_KERNEL_TYPES: Prefer kernel
This change adds a new flavor of dma-bufs that can be used by virtio
drivers to share exported objects. A virtio dma-buf can be queried by
virtio drivers to obtain the UUID which identifies the underlying
exported object.
Signed-off-by: David Stevens
---
drivers/virtio/Makefile | 2
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
include/uapi/
://markmail.org/thread/p5d3k566srtdtute
[3] https://markmail.org/thread/j4xlqaaim266qpks
v6 -> v7 changes:
- Fix most strict checkpatch comments
David Stevens (3):
virtio: add dma-buf support for exported objects
virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature
drm/virtio: Support virt
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
include/uapi/
20 at 10:25:15AM +0900, David Stevens wrote:
> > This patchset implements the current proposal for virtio cross-device
> > resource sharing [1]. It will be used to import virtio resources into
> > the virtio-video driver currently under discussion [2]. The patch
> > under
On Thu, Jun 18, 2020 at 9:29 PM Guennadi Liakhovetski
wrote:
>
> Hi Michael,
>
> On Thu, Jun 04, 2020 at 03:05:23PM -0400, Michael S. Tsirkin wrote:
> > On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote:
> > > This change adds a new flavor of dma-bufs
This change adds a new flavor of dma-bufs that can be used by virtio
drivers to share exported objects. A virtio dma-buf can be queried by
virtio drivers to obtain the UUID which identifies the underlying
exported object.
Signed-off-by: David Stevens
---
drivers/virtio/Makefile | 2
On Mon, Jun 8, 2020 at 6:43 PM Michael S. Tsirkin wrote:
>
> On Fri, May 15, 2020 at 04:26:15PM +0900, David Stevens wrote:
> > > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) {
> > > > + vgdev
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 +
drivers/gpu/drm/virtio/virtgpu_drv.h
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
include/uapi/
://markmail.org/thread/p5d3k566srtdtute
[3] https://markmail.org/thread/j4xlqaaim266qpks
v4 -> v5 changes:
- Remove virtio_dma_buf_export_info.
David Stevens (3):
virtio: add dma-buf support for exported objects
virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature
drm/virtio: Support virt
On Mon, Jun 8, 2020 at 6:05 PM Michael S. Tsirkin wrote:
>
> On Mon, Jun 08, 2020 at 05:32:26PM +0900, David Stevens wrote:
> > On Mon, Jun 8, 2020 at 3:00 PM Michael S. Tsirkin wrote:
> > >
> > > On Mon, Jun 08, 2020 at 10:33:09AM +0900, David Stevens wrote:
>
On Mon, Jun 8, 2020 at 3:00 PM Michael S. Tsirkin wrote:
>
> On Mon, Jun 08, 2020 at 10:33:09AM +0900, David Stevens wrote:
> > On Sun, Jun 7, 2020 at 5:04 AM Michael S. Tsirkin wrote:
> > >
> > > On Fri, Jun 05, 2020 at 10:28:42AM +0900, David Stevens wrote:
>
On Sun, Jun 7, 2020 at 5:04 AM Michael S. Tsirkin wrote:
>
> On Fri, Jun 05, 2020 at 10:28:42AM +0900, David Stevens wrote:
> > On Fri, Jun 5, 2020 at 4:05 AM Michael S. Tsirkin wrote:
> > >
> > > On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote:
On Fri, Jun 5, 2020 at 4:05 AM Michael S. Tsirkin wrote:
>
> On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote:
> > This change adds a new flavor of dma-bufs that can be used by virtio
> > drivers to share exported objects. A virtio dma-buf can be queried by
>
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
include/uapi/
This change adds a new flavor of dma-bufs that can be used by virtio
drivers to share exported objects. A virtio dma-buf can be queried by
virtio drivers to obtain the UUID which identifies the underlying
exported object.
Signed-off-by: David Stevens
---
drivers/virtio/Makefile | 2
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 +
drivers/gpu/drm/virtio/virtgpu_drv.h
ted
requirement that get_uuid only be called on attached virtio
dma-bufs is also removed.
- Rebase and add call to virtio_gpu_notify for ASSIGN_UUID.
David Stevens (3):
virtio: add dma-buf support for exported objects
virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature
drm/virtio: Support virt
> > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) {
> > + vgdev->has_resource_assign_uuid = true;
> > + }
>
>
> Just a question: this relies on DMA bufs so I assume it is
> not really assumed to work when DMA API is bypassed, right?
> Rather than worry what
On Thu, May 14, 2020 at 9:30 PM Daniel Vetter wrote:
> On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote:
> > Sorry for the duplicate reply, didn't notice this until now.
> >
> > > Just storing
> > > the uuid should be doable (assuming this doesn
Sorry for the duplicate reply, didn't notice this until now.
> Just storing
> the uuid should be doable (assuming this doesn't change during the
> lifetime of the buffer), so no need for a callback.
Directly storing the uuid doesn't work that well because of
synchronization issues. The uuid needs
On Thu, May 14, 2020 at 12:45 AM Daniel Vetter wrote:
> On Wed, Mar 11, 2020 at 12:20 PM David Stevens wrote:
> >
> > This change adds a new dma-buf operation that allows dma-bufs to be used
> > by virtio drivers to share exported objects. The new operation allows
> &
Simplify virtgpu_gem_prime_export as it can only be called once.
- Use virtio_gpu_vbuffer's objs field instead of abusing data_buf.
David Stevens (4):
dma-buf: add support for virtio exported objects
drm/prime: add support for virtio exported objects
virtio-gpu: add VIRTIO_GPU_F_RESOURCE
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
include/uapi/
This change exposes dma-buf's get_uuid callback to PRIME drivers.
Signed-off-by: David Stevens
---
drivers/gpu/drm/drm_prime.c | 23 +++
include/drm/drm_drv.h | 10 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gp
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++
drivers/gpu/drm/virtio/virtgpu_drv.h
This change adds a new dma-buf operation that allows dma-bufs to be used
by virtio drivers to share exported objects. The new operation allows
the importing driver to query the exporting driver for the UUID which
identifies the underlying exported object.
Signed-off-by: David Stevens
On Wed, Mar 4, 2020 at 5:01 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > + if (vgdev->has_resource_assign_uuid) {
> > + spin_lock(&vgdev->resource_export_lock);
> > + if (bo->uuid_state == UUID_NOT_INITIALIZED) {
> > + bo->uuid_state = UUID_INITIALIZING;
ack into main dma-buf ops (instead of placing it
in a new flavor of dma-buf).
- Rename new virtio commands and feature flag, and pull uapi changes
into their own patch.
David Stevens (4):
dma-buf: add support for virtio exported objects
drm/prime: add support for virtio exported objects
vi
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
include/uapi/
This change adds a new dma-buf operation that allows dma-bufs to be used
by virtio drivers to share exported objects. The new operation allows
the importing driver to query the exporting driver for the UUID which
identifies the underlying exported object.
Signed-off-by: David Stevens
> cmd_p->hdr.ctx_id =
>
> Before this completion of this hypercall, this resource can be
> considered context local, while afterward it can be considered
> "exported".
Maybe I'm misunderstanding render contexts, but exporting a resource
doesn't seem related to render contexts. The other resource m
This change exposes dma-buf's get_uuid callback to PRIME drivers.
Signed-off-by: David Stevens
---
drivers/gpu/drm/drm_prime.c | 27 +++
include/drm/drm_drv.h | 15 +++
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_prim
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++
drivers/gpu/drm/virtio/virtgpu_drv.h
On Tue, Feb 25, 2020 at 3:10 PM Gerd Hoffmann wrote:
>
> On Wed, Feb 19, 2020 at 05:06:36PM +0900, David Stevens wrote:
> > This change adds a new flavor of dma-bufs that can be used by virtio
> > drivers to share exported objects. A virtio dma-buf can be queried by
> >
Add support for exported resources to virtgpu. This includes adding
support for the new virtgpu command as well as well as switching from
regular prime dma-bufs to virtio dma-bufs.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 +
drivers/gpu/drm/virtio
/p5d3k566srtdtute
David Stevens (2):
virtio: add dma-buf support for exported objects
drm/virtio: Support virtgpu exported resources
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 21 +
drivers/gpu/drm/virtio/virtgpu_kms.c | 4 +
drivers/gpu/drm/virtio
This change adds a new flavor of dma-bufs that can be used by virtio
drivers to share exported objects. A virtio dma-buf can be queried by
virtio drivers to obtain the UUID which identifies the underlying
exported object.
Signed-off-by: David Stevens
---
drivers/virtio/Makefile | 2
74 matches
Mail list logo
