Re: [RFC] virtio-net: share receive_*() and add_recvbuf_*() with virtio-vsock
On Mon, Jul 15, 2019 at 01:50:28PM -0400, Michael S. Tsirkin wrote: > On Mon, Jul 15, 2019 at 09:44:16AM +0200, Stefano Garzarella wrote: > > On Fri, Jul 12, 2019 at 06:14:39PM +0800, Jason Wang wrote: [...] > > > > > > > > > I think it's just a branch, for ethernet, go for networking stack. > > > otherwise > > > go for vsock core? > > > > > > > Yes, that should work. > > > > So, I should refactor the functions that can be called also from the vsock > > core, in order to remove "struct net_device *dev" parameter. > > Maybe creating some wrappers for the network stack. > > > > Otherwise I should create a fake net_device for vsock_core. > > > > What do you suggest? > > Neither. > > I think what Jason was saying all along is this: > > virtio net doesn't actually lose packets, at least most > of the time. And it actually most of the time > passes all packets to host. So it's possible to use a virtio net > device (possibly with a feature flag that says "does not lose packets, > all packets go to host") and build vsock on top. Yes, I got it after the latest Jason's reply. > > and all of this is nice, but don't expect anything easy, > or any quick results. I expected this... :-( > > Also, in a sense it's a missed opportunity: we could cut out a lot > of fat and see just how fast can a protocol that is completely > new and separate from networking stack go. In this case, if we will try to do a PoC, what do you think is better? 1. new AF_VSOCK + network-stack + virtio-net modified Maybe it is allow us to reuse a lot of stuff already written, but we will go through the network stack 2. new AF_VSOCK + glue + virtio-net modified Intermediate approach, similar to Jason's proposal 3, new AF_VSOCK + new virtio-vsock Can be the thinnest, but we have to rewrite many things, with the risk of making the same mistakes as the current implementation. > Instead vsock implementation carries so much baggage from both > networking stack - such as softirq processing - and itself such as > workqueues, global state and crude locking - to the point where > it's actually slower than TCP. I agree, and I'm finding new issues while I'm trying to support nested VMs, allowing multiple vsock transports (virtio-vsock and vhost-vsock in the KVM case) at runtime. > [...] > > > > > > I suggest to do this step by step: > > > > > > 1) use virtio-net but keep some protocol logic > > > > > > 2) separate protocol logic and merge it to exist Linux networking stack > > > > Make sense, thanks for the suggestions, I'll try to do these steps! > > > > Thanks, > > Stefano > > > An alternative is look at sources of overhead in vsock and get rid of > them, or rewrite it from scratch focusing on performance. I started looking at virtio-vsock and vhost-vsock trying to do very simple changes [1] to increase the performance. I should send a v4 of that series as a very short term, then I'd like to have a deeper look to understand if it is better to try to optimize or rewrite it from scratch. Thanks, Stefano [1] https://patchwork.kernel.org/cover/10970145/ ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [RFC] virtio-net: share receive_*() and add_recvbuf_*() with virtio-vsock
On Tue, Jul 16, 2019 at 11:40:24AM +0200, Stefano Garzarella wrote: > On Mon, Jul 15, 2019 at 01:50:28PM -0400, Michael S. Tsirkin wrote: > > On Mon, Jul 15, 2019 at 09:44:16AM +0200, Stefano Garzarella wrote: > > > On Fri, Jul 12, 2019 at 06:14:39PM +0800, Jason Wang wrote: > > [...] > > > > > > > > > > > > > I think it's just a branch, for ethernet, go for networking stack. > > > > otherwise > > > > go for vsock core? > > > > > > > > > > Yes, that should work. > > > > > > So, I should refactor the functions that can be called also from the vsock > > > core, in order to remove "struct net_device *dev" parameter. > > > Maybe creating some wrappers for the network stack. > > > > > > Otherwise I should create a fake net_device for vsock_core. > > > > > > What do you suggest? > > > > Neither. > > > > I think what Jason was saying all along is this: > > > > virtio net doesn't actually lose packets, at least most > > of the time. And it actually most of the time > > passes all packets to host. So it's possible to use a virtio net > > device (possibly with a feature flag that says "does not lose packets, > > all packets go to host") and build vsock on top. > > Yes, I got it after the latest Jason's reply. > > > > > and all of this is nice, but don't expect anything easy, > > or any quick results. > > I expected this... :-( > > > > > Also, in a sense it's a missed opportunity: we could cut out a lot > > of fat and see just how fast can a protocol that is completely > > new and separate from networking stack go. > > In this case, if we will try to do a PoC, what do you think is better? > 1. new AF_VSOCK + network-stack + virtio-net modified > Maybe it is allow us to reuse a lot of stuff already written, > but we will go through the network stack > > 2. new AF_VSOCK + glue + virtio-net modified > Intermediate approach, similar to Jason's proposal > > 3, new AF_VSOCK + new virtio-vsock > Can be the thinnest, but we have to rewrite many things, with the risk > of making the same mistakes as the current implementation. > 1 or 3 imho. I wouldn't expect a lot from 2. I slightly favor 3 and Jason 1. So take your pick :) > > Instead vsock implementation carries so much baggage from both > > networking stack - such as softirq processing - and itself such as > > workqueues, global state and crude locking - to the point where > > it's actually slower than TCP. > > I agree, and I'm finding new issues while I'm trying to support nested > VMs, allowing multiple vsock transports (virtio-vsock and vhost-vsock in > the KVM case) at runtime. > > > > > [...] > > > > > > > > > I suggest to do this step by step: > > > > > > > > 1) use virtio-net but keep some protocol logic > > > > > > > > 2) separate protocol logic and merge it to exist Linux networking stack > > > > > > Make sense, thanks for the suggestions, I'll try to do these steps! > > > > > > Thanks, > > > Stefano > > > > > > An alternative is look at sources of overhead in vsock and get rid of > > them, or rewrite it from scratch focusing on performance. > > I started looking at virtio-vsock and vhost-vsock trying to do very > simple changes [1] to increase the performance. I should send a v4 of that > series as a very short term, then I'd like to have a deeper look to understand > if it is better to try to optimize or rewrite it from scratch. > > > Thanks, > Stefano > > [1] https://patchwork.kernel.org/cover/10970145/ ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [RFC] virtio-net: share receive_*() and add_recvbuf_*() with virtio-vsock
On Tue, Jul 16, 2019 at 06:01:33AM -0400, Michael S. Tsirkin wrote: > On Tue, Jul 16, 2019 at 11:40:24AM +0200, Stefano Garzarella wrote: > > On Mon, Jul 15, 2019 at 01:50:28PM -0400, Michael S. Tsirkin wrote: > > > On Mon, Jul 15, 2019 at 09:44:16AM +0200, Stefano Garzarella wrote: > > > > On Fri, Jul 12, 2019 at 06:14:39PM +0800, Jason Wang wrote: > > > > [...] > > > > > > > > > > > > > > > > > I think it's just a branch, for ethernet, go for networking stack. > > > > > otherwise > > > > > go for vsock core? > > > > > > > > > > > > > Yes, that should work. > > > > > > > > So, I should refactor the functions that can be called also from the > > > > vsock > > > > core, in order to remove "struct net_device *dev" parameter. > > > > Maybe creating some wrappers for the network stack. > > > > > > > > Otherwise I should create a fake net_device for vsock_core. > > > > > > > > What do you suggest? > > > > > > Neither. > > > > > > I think what Jason was saying all along is this: > > > > > > virtio net doesn't actually lose packets, at least most > > > of the time. And it actually most of the time > > > passes all packets to host. So it's possible to use a virtio net > > > device (possibly with a feature flag that says "does not lose packets, > > > all packets go to host") and build vsock on top. > > > > Yes, I got it after the latest Jason's reply. > > > > > > > > and all of this is nice, but don't expect anything easy, > > > or any quick results. > > > > I expected this... :-( > > > > > > > > Also, in a sense it's a missed opportunity: we could cut out a lot > > > of fat and see just how fast can a protocol that is completely > > > new and separate from networking stack go. > > > > In this case, if we will try to do a PoC, what do you think is better? > > 1. new AF_VSOCK + network-stack + virtio-net modified > > Maybe it is allow us to reuse a lot of stuff already written, > > but we will go through the network stack > > > > 2. new AF_VSOCK + glue + virtio-net modified > > Intermediate approach, similar to Jason's proposal > > > > 3, new AF_VSOCK + new virtio-vsock > > Can be the thinnest, but we have to rewrite many things, with the > > risk > > of making the same mistakes as the current implementation. > > > > 1 or 3 imho. I wouldn't expect a lot from 2. I slightly favor 3 and > Jason 1. So take your pick :) > Yes, I agree :) Maybe "Jason 1" could be the short term (and an opportunity to study better the code and sources of overhead) and "new AF_VSOCK + new virtio-vsock" the long term goal with the multi-transport support in mind. Thank you so much for your guidance and useful advice, Stefano ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PULL] virtio, vhost: fixes, features, performance
The following changes since commit c1ea02f15ab5efb3e93fc3144d895410bf79fcf2: vhost: scsi: add weight support (2019-05-27 11:08:23 -0400) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to 5e663f0410fa2f355042209154029842ba1abd43: virtio-mmio: add error check for platform_get_irq (2019-07-11 16:22:29 -0400) virtio, vhost: fixes, features, performance new iommu device vhost guest memory access using vmap (just meta-data for now) minor fixes Signed-off-by: Michael S. Tsirkin Note: due to code driver changes the driver-core tree, the following patch is needed when merging tree with commit 92ce7e83b4e5 ("driver_find_device: Unify the match function with class_find_device()") in the driver-core tree: From: Nathan Chancellor Subject: [PATCH] iommu/virtio: Constify data parameter in viommu_match_node After commit 92ce7e83b4e5 ("driver_find_device: Unify the match function with class_find_device()") in the driver-core tree. Signed-off-by: Nathan Chancellor Signed-off-by: Michael S. Tsirkin --- drivers/iommu/virtio-iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c index 4620dd221ffd..433f4d2ee956 100644 --- a/drivers/iommu/virtio-iommu.c +++ b/drivers/iommu/virtio-iommu.c @@ -839,7 +839,7 @@ static void viommu_put_resv_regions(struct device *dev, struct list_head *head) static struct iommu_ops viommu_ops; static struct virtio_driver virtio_iommu_drv; -static int viommu_match_node(struct device *dev, void *data) +static int viommu_match_node(struct device *dev, const void *data) { return dev->parent->fwnode == data; } Gustavo A. R. Silva (1): scsi: virtio_scsi: Use struct_size() helper Ihor Matushchak (1): virtio-mmio: add error check for platform_get_irq Jason Wang (6): vhost: generalize adding used elem vhost: fine grain userspace memory accessors vhost: rename vq_iotlb_prefetch() to vq_meta_prefetch() vhost: introduce helpers to get the size of metadata area vhost: factor out setting vring addr and num vhost: access vq metadata through kernel virtual address Jean-Philippe Brucker (7): dt-bindings: virtio-mmio: Add IOMMU description dt-bindings: virtio: Add virtio-pci-iommu node of: Allow the iommu-map property to omit untranslated devices PCI: OF: Initialize dev->fwnode appropriately iommu: Add virtio-iommu driver iommu/virtio: Add probe request iommu/virtio: Add event queue Michael S. Tsirkin (1): vhost: fix clang build warning Documentation/devicetree/bindings/virtio/iommu.txt | 66 ++ Documentation/devicetree/bindings/virtio/mmio.txt | 30 + MAINTAINERS|7 + drivers/iommu/Kconfig | 11 + drivers/iommu/Makefile |1 + drivers/iommu/virtio-iommu.c | 1158 drivers/of/base.c | 10 +- drivers/pci/of.c |8 + drivers/scsi/virtio_scsi.c |2 +- drivers/vhost/net.c|4 +- drivers/vhost/vhost.c | 850 +++--- drivers/vhost/vhost.h | 43 +- drivers/virtio/virtio_mmio.c |7 +- include/uapi/linux/virtio_ids.h|1 + include/uapi/linux/virtio_iommu.h | 161 +++ 15 files changed, 2228 insertions(+), 131 deletions(-) create mode 100644 Documentation/devicetree/bindings/virtio/iommu.txt create mode 100644 drivers/iommu/virtio-iommu.c create mode 100644 include/uapi/linux/virtio_iommu.h ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v2 2/3] drm: plumb attaching dev thru to prime_pin/unpin
From: Rob Clark Needed in the following patch for cache operations. Signed-off-by: Rob Clark --- drivers/gpu/drm/drm_gem.c | 10 ++ drivers/gpu/drm/drm_gem_vram_helper.c | 6 -- drivers/gpu/drm/drm_prime.c | 4 ++-- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 4 ++-- drivers/gpu/drm/msm/msm_drv.h | 4 ++-- drivers/gpu/drm/msm/msm_gem_prime.c | 4 ++-- drivers/gpu/drm/nouveau/nouveau_gem.h | 4 ++-- drivers/gpu/drm/nouveau/nouveau_prime.c | 4 ++-- drivers/gpu/drm/qxl/qxl_prime.c | 4 ++-- drivers/gpu/drm/radeon/radeon_prime.c | 4 ++-- drivers/gpu/drm/vboxvideo/vbox_prime.c | 4 ++-- drivers/gpu/drm/vgem/vgem_drv.c | 4 ++-- include/drm/drm_drv.h | 4 ++-- include/drm/drm_gem.h | 4 ++-- include/drm/drm_gem_vram_helper.h | 4 ++-- 15 files changed, 36 insertions(+), 32 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 7d6242cc69f2..0a2645769624 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1219,18 +1219,19 @@ void drm_gem_print_info(struct drm_printer *p, unsigned int indent, /** * drm_gem_pin - Pin backing buffer in memory * @obj: GEM object + * @dev: the device the buffer is being pinned for * * Make sure the backing buffer is pinned in memory. * * Returns: * 0 on success or a negative error code on failure. */ -int drm_gem_pin(struct drm_gem_object *obj) +int drm_gem_pin(struct drm_gem_object *obj, struct device *dev) { if (obj->funcs && obj->funcs->pin) return obj->funcs->pin(obj); else if (obj->dev->driver->gem_prime_pin) - return obj->dev->driver->gem_prime_pin(obj); + return obj->dev->driver->gem_prime_pin(obj, dev); else return 0; } @@ -1239,15 +1240,16 @@ EXPORT_SYMBOL(drm_gem_pin); /** * drm_gem_unpin - Unpin backing buffer from memory * @obj: GEM object + * @dev: the device the buffer is being pinned for * * Relax the requirement that the backing buffer is pinned in memory. */ -void drm_gem_unpin(struct drm_gem_object *obj) +void drm_gem_unpin(struct drm_gem_object *obj, struct device *dev) { if (obj->funcs && obj->funcs->unpin) obj->funcs->unpin(obj); else if (obj->dev->driver->gem_prime_unpin) - obj->dev->driver->gem_prime_unpin(obj); + obj->dev->driver->gem_prime_unpin(obj, dev); } EXPORT_SYMBOL(drm_gem_unpin); diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c index 4de782ca26b2..62fafec93948 100644 --- a/drivers/gpu/drm/drm_gem_vram_helper.c +++ b/drivers/gpu/drm/drm_gem_vram_helper.c @@ -548,7 +548,8 @@ EXPORT_SYMBOL(drm_gem_vram_driver_dumb_mmap_offset); * 0 on success, or * a negative errno code otherwise. */ -int drm_gem_vram_driver_gem_prime_pin(struct drm_gem_object *gem) +int drm_gem_vram_driver_gem_prime_pin(struct drm_gem_object *gem, + struct device *dev) { struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem); @@ -569,7 +570,8 @@ EXPORT_SYMBOL(drm_gem_vram_driver_gem_prime_pin); Implements &struct drm_driver.gem_prime_unpin * @gem: The GEM object to unpin */ -void drm_gem_vram_driver_gem_prime_unpin(struct drm_gem_object *gem) +void drm_gem_vram_driver_gem_prime_unpin(struct drm_gem_object *gem, +struct device *dev) { struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem); diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index d0c01318076b..505893cfac8e 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -196,7 +196,7 @@ int drm_gem_map_attach(struct dma_buf *dma_buf, { struct drm_gem_object *obj = dma_buf->priv; - return drm_gem_pin(obj); + return drm_gem_pin(obj, attach->dev); } EXPORT_SYMBOL(drm_gem_map_attach); @@ -213,7 +213,7 @@ void drm_gem_map_detach(struct dma_buf *dma_buf, { struct drm_gem_object *obj = dma_buf->priv; - drm_gem_unpin(obj); + drm_gem_unpin(obj, attach->dev); } EXPORT_SYMBOL(drm_gem_map_detach); diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c index 00e8b6a817e3..44385d590aa7 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c @@ -43,7 +43,7 @@ int etnaviv_gem_prime_mmap(struct drm_gem_object *obj, return etnaviv_obj->ops->mmap(etnaviv_obj, vma); } -int etnaviv_gem_prime_pin(struct drm_gem_object *obj) +int etnaviv_gem_prime_pin(struct drm_gem_object *obj, struct device *dev) { if (!obj->import_attach) { struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj); @@ -55,7 +55,7 @@ int etnaviv_gem_prime_pin(stru
Re: [PATCH v2 2/3] drm: plumb attaching dev thru to prime_pin/unpin
Quoting Rob Clark (2019-07-16 18:43:22) > From: Rob Clark > > Needed in the following patch for cache operations. What's the base for this patch? (I'm missing the ancestor for drm_gem.c) -Chris ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v3 2/3] drm: plumb attaching dev thru to prime_pin/unpin
From: Rob Clark Needed in the following patch for cache operations. Signed-off-by: Rob Clark --- v3: rebased on drm-tip drivers/gpu/drm/drm_gem.c | 8 drivers/gpu/drm/drm_internal.h | 4 ++-- drivers/gpu/drm/drm_prime.c | 4 ++-- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 4 ++-- drivers/gpu/drm/msm/msm_drv.h | 4 ++-- drivers/gpu/drm/msm/msm_gem_prime.c | 4 ++-- drivers/gpu/drm/nouveau/nouveau_gem.h | 4 ++-- drivers/gpu/drm/nouveau/nouveau_prime.c | 4 ++-- drivers/gpu/drm/qxl/qxl_prime.c | 4 ++-- drivers/gpu/drm/radeon/radeon_prime.c | 4 ++-- drivers/gpu/drm/vgem/vgem_drv.c | 4 ++-- include/drm/drm_drv.h | 5 ++--- 12 files changed, 26 insertions(+), 27 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 84689ccae885..af2549c45027 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1215,22 +1215,22 @@ void drm_gem_print_info(struct drm_printer *p, unsigned int indent, obj->dev->driver->gem_print_info(p, indent, obj); } -int drm_gem_pin(struct drm_gem_object *obj) +int drm_gem_pin(struct drm_gem_object *obj, struct device *dev) { if (obj->funcs && obj->funcs->pin) return obj->funcs->pin(obj); else if (obj->dev->driver->gem_prime_pin) - return obj->dev->driver->gem_prime_pin(obj); + return obj->dev->driver->gem_prime_pin(obj, dev); else return 0; } -void drm_gem_unpin(struct drm_gem_object *obj) +void drm_gem_unpin(struct drm_gem_object *obj, struct device *dev) { if (obj->funcs && obj->funcs->unpin) obj->funcs->unpin(obj); else if (obj->dev->driver->gem_prime_unpin) - obj->dev->driver->gem_prime_unpin(obj); + obj->dev->driver->gem_prime_unpin(obj, dev); } void *drm_gem_vmap(struct drm_gem_object *obj) diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h index 51a2055c8f18..e64090373e3a 100644 --- a/drivers/gpu/drm/drm_internal.h +++ b/drivers/gpu/drm/drm_internal.h @@ -133,8 +133,8 @@ void drm_gem_release(struct drm_device *dev, struct drm_file *file_private); void drm_gem_print_info(struct drm_printer *p, unsigned int indent, const struct drm_gem_object *obj); -int drm_gem_pin(struct drm_gem_object *obj); -void drm_gem_unpin(struct drm_gem_object *obj); +int drm_gem_pin(struct drm_gem_object *obj, struct device *dev); +void drm_gem_unpin(struct drm_gem_object *obj, struct device *dev); void *drm_gem_vmap(struct drm_gem_object *obj); void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr); diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 189d980402ad..126860432ff9 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -575,7 +575,7 @@ int drm_gem_map_attach(struct dma_buf *dma_buf, { struct drm_gem_object *obj = dma_buf->priv; - return drm_gem_pin(obj); + return drm_gem_pin(obj, attach->dev); } EXPORT_SYMBOL(drm_gem_map_attach); @@ -593,7 +593,7 @@ void drm_gem_map_detach(struct dma_buf *dma_buf, { struct drm_gem_object *obj = dma_buf->priv; - drm_gem_unpin(obj); + drm_gem_unpin(obj, attach->dev); } EXPORT_SYMBOL(drm_gem_map_detach); diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c index a05292e8ed6f..67e69a5f00f2 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c @@ -43,7 +43,7 @@ int etnaviv_gem_prime_mmap(struct drm_gem_object *obj, return etnaviv_obj->ops->mmap(etnaviv_obj, vma); } -int etnaviv_gem_prime_pin(struct drm_gem_object *obj) +int etnaviv_gem_prime_pin(struct drm_gem_object *obj, struct device *dev) { if (!obj->import_attach) { struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj); @@ -55,7 +55,7 @@ int etnaviv_gem_prime_pin(struct drm_gem_object *obj) return 0; } -void etnaviv_gem_prime_unpin(struct drm_gem_object *obj) +void etnaviv_gem_prime_unpin(struct drm_gem_object *obj, struct device *dev) { if (!obj->import_attach) { struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj); diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h index ee7b512dc158..0eea68618b68 100644 --- a/drivers/gpu/drm/msm/msm_drv.h +++ b/drivers/gpu/drm/msm/msm_drv.h @@ -288,8 +288,8 @@ void msm_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr); int msm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma); struct drm_gem_object *msm_gem_prime_import_sg_table(struct drm_device *dev, struct dma_buf_attachment *attach, struct sg_table *sg); -int msm_gem_prime_pin(struct drm_gem_object *obj); -void msm_gem_prime_unpin(struc
Re: [PATCH v3] virtio_pmem: fix sparse warning
On Fri, Jul 12, 2019 at 7:11 AM Michael S. Tsirkin wrote: > > On Fri, Jul 12, 2019 at 10:46:10AM +0530, Pankaj Gupta wrote: > > This patch fixes below sparse warning related to __virtio > > type in virtio pmem driver. This is reported by Intel test > > bot on linux-next tree. > > > > nd_virtio.c:56:28: warning: incorrect type in assignment > > (different base types) > > nd_virtio.c:56:28:expected unsigned int [unsigned] [usertype] type > > nd_virtio.c:56:28:got restricted __virtio32 > > nd_virtio.c:93:59: warning: incorrect type in argument 2 > > (different base types) > > nd_virtio.c:93:59:expected restricted __virtio32 [usertype] val > > nd_virtio.c:93:59:got unsigned int [unsigned] [usertype] ret > > > > Reported-by: kbuild test robot > > Signed-off-by: Pankaj Gupta > > Acked-by: Michael S. Tsirkin > > Pls merge - I assume nvdimm tree? Yes, I'll push this with the rest to Linus tomorrow morning. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v6 11/18] drm/virtio: switch from ttm to gem shmem helpers
On Tue, Jul 2, 2019 at 7:19 AM Gerd Hoffmann wrote: > > virtio-gpu basically needs a sg_table for the bo, to tell the host where > the backing pages for the object are. So the gem shmem helpers are a > perfect fit. Some drm_gem_object_funcs need thin wrappers to update the > host state, but otherwise the helpers handle everything just fine. > > Once the fencing was sorted the switch was surprisingly easy and for the > most part just removing the ttm code. > > v4: fix drm_gem_object_funcs name. > > Signed-off-by: Gerd Hoffmann > Acked-by: Daniel Vetter > --- > drivers/gpu/drm/virtio/virtgpu_drv.h| 52 +--- > drivers/gpu/drm/virtio/virtgpu_drv.c| 20 +- > drivers/gpu/drm/virtio/virtgpu_gem.c| 16 +- > drivers/gpu/drm/virtio/virtgpu_ioctl.c | 19 +- > drivers/gpu/drm/virtio/virtgpu_kms.c| 9 - > drivers/gpu/drm/virtio/virtgpu_object.c | 146 > drivers/gpu/drm/virtio/virtgpu_prime.c | 37 --- > drivers/gpu/drm/virtio/virtgpu_ttm.c| 304 > drivers/gpu/drm/virtio/virtgpu_vq.c | 24 +- > drivers/gpu/drm/virtio/Kconfig | 2 +- > drivers/gpu/drm/virtio/Makefile | 2 +- > 11 files changed, 82 insertions(+), 549 deletions(-) > delete mode 100644 drivers/gpu/drm/virtio/virtgpu_ttm.c > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h > b/drivers/gpu/drm/virtio/virtgpu_drv.h > index 12168067a874..f8a586029400 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h > @@ -33,14 +33,11 @@ > > #include > #include > +#include > #include > #include > #include > #include > -#include > -#include > -#include > -#include > > #define DRIVER_NAME "virtio_gpu" > #define DRIVER_DESC "virtio GPU" > @@ -68,21 +65,16 @@ struct virtio_gpu_object_params { > }; > > struct virtio_gpu_object { > - struct drm_gem_object gem_base; > + struct drm_gem_shmem_object base; > uint32_t hw_res_handle; > > struct sg_table *pages; > uint32_t mapped; > - void *vmap; > bool dumb; > - struct ttm_placeplacement_code; > - struct ttm_placementplacement; > - struct ttm_buffer_objecttbo; > - struct ttm_bo_kmap_obj kmap; > bool created; > }; > #define gem_to_virtio_gpu_obj(gobj) \ > - container_of((gobj), struct virtio_gpu_object, gem_base) > + container_of((gobj), struct virtio_gpu_object, base.base) > > struct virtio_gpu_object_array { > struct ww_acquire_ctx ticket; > @@ -153,10 +145,6 @@ struct virtio_gpu_framebuffer { > #define to_virtio_gpu_framebuffer(x) \ > container_of(x, struct virtio_gpu_framebuffer, base) > > -struct virtio_gpu_mman { > - struct ttm_bo_devicebdev; > -}; > - > struct virtio_gpu_queue { > struct virtqueue *vq; > spinlock_t qlock; > @@ -185,8 +173,6 @@ struct virtio_gpu_device { > > struct virtio_device *vdev; > > - struct virtio_gpu_mman mman; > - > struct virtio_gpu_output outputs[VIRTIO_GPU_MAX_SCANOUTS]; > uint32_t num_scanouts; > > @@ -357,11 +343,6 @@ struct drm_plane *virtio_gpu_plane_init(struct > virtio_gpu_device *vgdev, > enum drm_plane_type type, > int index); > > -/* virtio_gpu_ttm.c */ > -int virtio_gpu_ttm_init(struct virtio_gpu_device *vgdev); > -void virtio_gpu_ttm_fini(struct virtio_gpu_device *vgdev); > -int virtio_gpu_mmap(struct file *filp, struct vm_area_struct *vma); > - > /* virtio_gpu_fence.c */ > bool virtio_fence_signaled(struct dma_fence *f); > struct virtio_gpu_fence *virtio_gpu_fence_alloc( > @@ -373,58 +354,47 @@ void virtio_gpu_fence_event_process(struct > virtio_gpu_device *vdev, > u64 last_seq); > > /* virtio_gpu_object */ > +struct drm_gem_object *virtio_gpu_create_object(struct drm_device *dev, > + size_t size); > int virtio_gpu_object_create(struct virtio_gpu_device *vgdev, > struct virtio_gpu_object_params *params, > struct virtio_gpu_object **bo_ptr, > struct virtio_gpu_fence *fence); > -void virtio_gpu_object_kunmap(struct virtio_gpu_object *bo); > -int virtio_gpu_object_kmap(struct virtio_gpu_object *bo); > -int virtio_gpu_object_get_sg_table(struct virtio_gpu_device *qdev, > - struct virtio_gpu_object *bo); > -void virtio_gpu_object_free_sg_table(struct virtio_gpu_object *bo); > > /* virtgpu_prime.c */ > -struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj); > struct drm_gem_object *virtgpu_gem_prime_import_sg_table( > struct drm_device *dev, struct dma_buf_attachment *attach, > struct sg_table *sgt); > -void *virtgpu_gem_prime_vmap(struct drm_gem_object *obj); > -void virtgpu_gem_prime_vu
Re: [PATCH v3 2/3] drm: plumb attaching dev thru to prime_pin/unpin
Am 16.07.19 um 23:37 schrieb Rob Clark: > From: Rob Clark > > Needed in the following patch for cache operations. Well have you seen that those callbacks are deprecated? >* Deprecated hook in favour of &drm_gem_object_funcs.pin. >* Deprecated hook in favour of &drm_gem_object_funcs.unpin. > I would rather say if you want to extend something it would be better to switch over to the per GEM object functions first. Regards, Christian. > > Signed-off-by: Rob Clark > --- > v3: rebased on drm-tip > > drivers/gpu/drm/drm_gem.c | 8 > drivers/gpu/drm/drm_internal.h | 4 ++-- > drivers/gpu/drm/drm_prime.c | 4 ++-- > drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 4 ++-- > drivers/gpu/drm/msm/msm_drv.h | 4 ++-- > drivers/gpu/drm/msm/msm_gem_prime.c | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_gem.h | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_prime.c | 4 ++-- > drivers/gpu/drm/qxl/qxl_prime.c | 4 ++-- > drivers/gpu/drm/radeon/radeon_prime.c | 4 ++-- > drivers/gpu/drm/vgem/vgem_drv.c | 4 ++-- > include/drm/drm_drv.h | 5 ++--- > 12 files changed, 26 insertions(+), 27 deletions(-) > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > index 84689ccae885..af2549c45027 100644 > --- a/drivers/gpu/drm/drm_gem.c > +++ b/drivers/gpu/drm/drm_gem.c > @@ -1215,22 +1215,22 @@ void drm_gem_print_info(struct drm_printer *p, > unsigned int indent, > obj->dev->driver->gem_print_info(p, indent, obj); > } > > -int drm_gem_pin(struct drm_gem_object *obj) > +int drm_gem_pin(struct drm_gem_object *obj, struct device *dev) > { > if (obj->funcs && obj->funcs->pin) > return obj->funcs->pin(obj); > else if (obj->dev->driver->gem_prime_pin) > - return obj->dev->driver->gem_prime_pin(obj); > + return obj->dev->driver->gem_prime_pin(obj, dev); > else > return 0; > } > > -void drm_gem_unpin(struct drm_gem_object *obj) > +void drm_gem_unpin(struct drm_gem_object *obj, struct device *dev) > { > if (obj->funcs && obj->funcs->unpin) > obj->funcs->unpin(obj); > else if (obj->dev->driver->gem_prime_unpin) > - obj->dev->driver->gem_prime_unpin(obj); > + obj->dev->driver->gem_prime_unpin(obj, dev); > } > > void *drm_gem_vmap(struct drm_gem_object *obj) > diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h > index 51a2055c8f18..e64090373e3a 100644 > --- a/drivers/gpu/drm/drm_internal.h > +++ b/drivers/gpu/drm/drm_internal.h > @@ -133,8 +133,8 @@ void drm_gem_release(struct drm_device *dev, struct > drm_file *file_private); > void drm_gem_print_info(struct drm_printer *p, unsigned int indent, > const struct drm_gem_object *obj); > > -int drm_gem_pin(struct drm_gem_object *obj); > -void drm_gem_unpin(struct drm_gem_object *obj); > +int drm_gem_pin(struct drm_gem_object *obj, struct device *dev); > +void drm_gem_unpin(struct drm_gem_object *obj, struct device *dev); > void *drm_gem_vmap(struct drm_gem_object *obj); > void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr); > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c > index 189d980402ad..126860432ff9 100644 > --- a/drivers/gpu/drm/drm_prime.c > +++ b/drivers/gpu/drm/drm_prime.c > @@ -575,7 +575,7 @@ int drm_gem_map_attach(struct dma_buf *dma_buf, > { > struct drm_gem_object *obj = dma_buf->priv; > > - return drm_gem_pin(obj); > + return drm_gem_pin(obj, attach->dev); > } > EXPORT_SYMBOL(drm_gem_map_attach); > > @@ -593,7 +593,7 @@ void drm_gem_map_detach(struct dma_buf *dma_buf, > { > struct drm_gem_object *obj = dma_buf->priv; > > - drm_gem_unpin(obj); > + drm_gem_unpin(obj, attach->dev); > } > EXPORT_SYMBOL(drm_gem_map_detach); > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c > b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c > index a05292e8ed6f..67e69a5f00f2 100644 > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c > @@ -43,7 +43,7 @@ int etnaviv_gem_prime_mmap(struct drm_gem_object *obj, > return etnaviv_obj->ops->mmap(etnaviv_obj, vma); > } > > -int etnaviv_gem_prime_pin(struct drm_gem_object *obj) > +int etnaviv_gem_prime_pin(struct drm_gem_object *obj, struct device *dev) > { > if (!obj->import_attach) { > struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj); > @@ -55,7 +55,7 @@ int etnaviv_gem_prime_pin(struct drm_gem_object *obj) > return 0; > } > > -void etnaviv_gem_prime_unpin(struct drm_gem_object *obj) > +void etnaviv_gem_prime_unpin(struct drm_gem_object *obj, struct device *dev) > { > if (!obj->import_attach) { > struct etnaviv_gem_object *etnaviv_obj = to_etnaviv