Re: Xorg indefinitely hangs in kernelspace

On 05.09.19 10:14, Gerd Hoffmann wrote: > On Tue, Aug 06, 2019 at 09:00:10PM +0300, Jaak Ristioja wrote: >> Hello! >> >> I'm writing to report a crash in the QXL / DRM code in the Linux kernel. >> I originally filed the issue on LaunchPad and more details can be found >> there, although I doubt

Re: [PATCH 0/2] Revert and rework on the metadata accelreation

On Thu, Sep 05, 2019 at 08:27:34PM +0800, Jason Wang wrote: > Hi: > > Per request from Michael and Jason, the metadata accelreation is > reverted in this version and rework in next version. > > Please review. > > Thanks > > Jason Wang (2): > Revert "vhost: access vq metadata through kernel

[PATCH 2/2] vhost: re-introducing metadata acceleration through kernel virtual address

This is a rework on the commit 7f466032dc9e ("vhost: access vq metadata through kernel virtual address"). It was noticed that the copy_to/from_user() friends that was used to access virtqueue metdata tends to be very expensive for dataplane implementation like vhost since it involves lots of

[PATCH 1/2] Revert "vhost: access vq metadata through kernel virtual address"

It was reported that metadata acceleration introduces several issues, so this patch reverts commit ff466032dc9e5a61217f22ea34b2df932786bbfc, 73f628ec9e6bcc45b77c53fe6d0c0ec55eaf82af and 0b4a7092ffe568a55bf8f3cefdf79ff666586d91. We will rework it on the next version. Cc: Jason Gunthorpe

[PATCH 00/18] virtiofs: Fix various races and cleanups round 1

Hi, Michael Tsirkin pointed out issues w.r.t various locking related TODO items and races w.r.t device removal. In this first round of cleanups, I have taken care of most pressing issues. These patches apply on top of following.

[PATCH 01/18] virtiofs: Remove request from processing list before calling end

In error path we are calling fuse_request_end() but we need to clear FR_SENT bit as well as remove request from processing queue. Otherwise fuse_request_end() triggers a warning as well as other issues show up. Signed-off-by: Vivek Goyal --- fs/fuse/virtio_fs.c | 4 1 file changed, 4

[PATCH 02/18] virtiofs: Check whether hiprio queue is connected at submission time

For hiprio queue (forget requests), we are keeping a state in queue whether queue is connected or not. If queue is not connected, do not try to submit request and return error instead. As of now, we are checking for this state only in path where worker tries to submit forget after first attempt

[PATCH 11/18] virtiofs: stop and drain queues after sending DESTROY

During virtio_kill_sb() we first stop forget queue and drain it and then call fuse_kill_sb_anon(). This will result in sending DESTROY request to fuse server. Once finished, stop all the queues and drain one more time just to be sure and then free up the devices. Given drain queues will call

[PATCH 15/18] virtiofs: Make virtio_fs object refcounted

This object is used both by fuse_connection as well virt device. So make this object reference counted and that makes it easy to define life cycle of the object. Now deivce can be removed while filesystem is still mounted. This will cleanup all the virtqueues but virtio_fs object will still be

[PATCH 06/18] virtiofs: ->remove should not clean virtiofs fuse devices

We maintain a fuse device per virt queue. This fuse devices are allocated and installed during mount time and should be cleaned up when super block is going away. Device removal should not clean it. Device removal should stop queues and virtuques can go away. Signed-off-by: Vivek Goyal ---

[PATCH 12/18] virtiofs: Use virtio_fs_free_devs() in error path

We already have an helper to cleanup fuse devices. Use that instead of duplicating the code. Signed-off-by: Vivek Goyal --- fs/fuse/virtio_fs.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c index a76bd5a04521..40259368a6bd 100644

[PATCH 07/18] virtiofs: Stop virtiofs queues when device is being removed

Stop all the virt queues when device is going away. This will ensure that no new requests are submitted to virtqueue and and request will end with error -ENOTCONN. Signed-off-by: Vivek Goyal --- fs/fuse/virtio_fs.c | 14 ++ 1 file changed, 14 insertions(+) diff --git

[PATCH 08/18] virtiofs: Drain all pending requests during ->remove time

When device is going away, drain all pending requests. Signed-off-by: Vivek Goyal --- fs/fuse/virtio_fs.c | 83 - 1 file changed, 51 insertions(+), 32 deletions(-) diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c index

[PATCH 04/18] virtiofs: Check connected state for VQ_REQUEST queue as well

Right now we are checking ->connected state only for VQ_HIPRIO. Now we want to make use of this method for all queues. So check it for VQ_REQUEST as well. This will be helpful if device has been removed and virtqueue is gone. In that case ->connected will be false and request can't be submitted

Re: DANGER WILL ROBINSON, DANGER

On Fri, Aug 23, 2019 at 12:39:21PM +, Mircea CIRJALIU - MELIU wrote: > > On Thu, Aug 15, 2019 at 03:19:29PM -0400, Jerome Glisse wrote: > > > On Tue, Aug 13, 2019 at 02:01:35PM +0300, Adalbert Lazăr wrote: > > > > On Fri, 9 Aug 2019 09:24:44 -0700, Matthew Wilcox > > wrote: > > > > > On Fri,

[PATCH 05/18] Maintain count of in flight requests for VQ_REQUEST queue

As of now we maintain this count only for VQ_HIPRIO. Maintain it for VQ_REQUEST as well so that later it can be used to drain VQ_REQUEST queue. Signed-off-by: Vivek Goyal --- fs/fuse/virtio_fs.c | 4 1 file changed, 4 insertions(+) diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c

[PATCH 16/18] virtiofs: Use virtio_fs_mutex for races w.r.t ->remove and mount path

It is possible that a mount is in progress and device is being removed at the same time. Use virtio_fs_mutex to avoid races. This also takes care of bunch of races and removes some TODO items. Signed-off-by: Vivek Goyal --- fs/fuse/virtio_fs.c | 32 ++-- 1 file

[PATCH 13/18] virtiofs: Do not access virtqueue in request submission path

In request submission path it is possible that virtqueue is already gone due to driver->remove(). So do not access it in dev_dbg(). Use pr_debug() instead. If virtuqueue is gone, this will result in NULL pointer deference. Signed-off-by: Vivek Goyal --- fs/fuse/virtio_fs.c | 8 1 file

[PATCH 17/18] virtiofs: Remove TODO to quiesce/end_requests

We now stop queues and drain all the pending requests from all virtqueues. So this is not a TODO anymore. Got rid of incrementing fc->dev_count as well. It did not seem meaningful for virtio_fs. Signed-off-by: Vivek Goyal --- fs/fuse/virtio_fs.c | 2 -- 1 file changed, 2 deletions(-) diff

[PATCH 09/18] virtiofs: Add an helper to start all the queues

This just marks are the queues are connected and ready to accept the request. Signed-off-by: Vivek Goyal --- fs/fuse/virtio_fs.c | 19 --- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c index d5730a50b303..f2936daca39c

[PATCH 10/18] virtiofs: Do not use device managed mem for virtio_fs and virtio_fs_vq

These data structures should go away when virtio_fs object is going away. When deivce is going away, we need to just make sure virtqueues can go away and after that none of the code accesses vq and all the requests get error. So allocate memory for virtio_fs and virtio_fs_vq normally and free it

[PATCH 18/18] virtiofs: Remove TODO item from virtio_fs_free_devs()

virtio_fs_free_devs() is now called from ->kill_sb(). By this time all device queues have been quiesced. I am assuming that while ->kill_sb() is in progress, another mount instance will wait for it to finish (sb->s_umount mutex provides mutual exclusion). W.r.t ->remove path, we should be fine as

[PATCH 03/18] virtiofs: Pass fsvq instead of vq as parameter to virtio_fs_enqueue_req

Pass fsvq instead of vq as parameter to virtio_fs_enqueue_req(). We will retrieve vq from fsvq under spin lock. Later in the patch series we will retrieve vq only if fsvq is still connected other vq might have been cleaned up by device ->remove code and we will return error. Signed-off-by: Vivek

Re: [PATCH] drm/virtio: fix command submission with objects but without fence.

On Wed, Sep 4, 2019 at 10:23 PM Gerd Hoffmann wrote: > > On Wed, Sep 04, 2019 at 04:10:30PM -0700, Chia-I Wu wrote: > > On Wed, Sep 4, 2019 at 12:48 AM Gerd Hoffmann wrote: > > > > > > Only call virtio_gpu_array_add_fence if we actually have a fence. > > > > > > Fixes: da758d51968a ("drm/virtio:

Re: [PATCH v4 15/16] virtio-fs: add virtiofs filesystem

On Tue, Sep 03, 2019 at 09:55:49AM -0400, Michael S. Tsirkin wrote: [..] > What's with all of the TODOs? Some of these are really scary, > looks like they need to be figured out before this is merged. Hi Michael, One of the issue I noticed is races w.r.t device removal and super block

[PATCH v2] drm/virtio: Use vmalloc for command buffer allocations.

Userspace requested command buffer allocations could be too large to make as a contiguous allocation. Use vmalloc if necessary to satisfy those allocations. Signed-off-by: David Riley --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 +- drivers/gpu/drm/virtio/virtgpu_vq.c| 114

Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted

On Mon, Aug 12, 2019 at 02:15:32PM +0200, Christoph Hellwig wrote: > On Sun, Aug 11, 2019 at 04:55:27AM -0400, Michael S. Tsirkin wrote: > > On Sun, Aug 11, 2019 at 07:56:07AM +0200, Christoph Hellwig wrote: > > > So we need a flag on the virtio device, exposed by the > > > hypervisor (or hardware

Re: [PATCH v2] drm/virtio: Use vmalloc for command buffer allocations.

> +/* How many bytes left in this page. */ > +static unsigned int rest_of_page(void *data) > +{ > + return PAGE_SIZE - offset_in_page(data); > +} Not needed. > +/* Create sg_table from a vmalloc'd buffer. */ > +static struct sg_table *vmalloc_to_sgt(char *data, uint32_t size, int >

Re: Xorg indefinitely hangs in kernelspace

On Tue, 6 Aug 2019 21:00:10 +0300 From: Jaak Ristioja > Hello! > > I'm writing to report a crash in the QXL / DRM code in the Linux kernel. > I originally filed the issue on LaunchPad and more details can be found > there, although I doubt whether these details are useful. > >

Re: [PATCH V5 0/5] iommu/amd: Convert the AMD iommu driver to the dma-iommu api

Dave, Joerg, Robin: is there any chance we could at least pick up patches 2 and 4 ASAP as they are clearly fixes for current deficits, even without the amd conversion? ___ Virtualization mailing list Virtualization@lists.linux-foundation.org

Re: Xorg indefinitely hangs in kernelspace

On Tue, Aug 06, 2019 at 09:00:10PM +0300, Jaak Ristioja wrote: > Hello! > > I'm writing to report a crash in the QXL / DRM code in the Linux kernel. > I originally filed the issue on LaunchPad and more details can be found > there, although I doubt whether these details are useful. Any change

[PATCH 1/8] drm/ttm: turn ttm_bo_device.vma_manager into a pointer

Rename the embedded struct vma_offset_manager, new name is _vma_manager. ttm_bo_device.vma_manager changed to a pointer. The ttm_bo_device_init() function gets an additional vma_manager argument which allows to initialize ttm with a different vma manager. When passing NULL the embedded

[PATCH 6/8] drm/qxl: switch to gem vma offset manager

Pass gem vma_offset_manager to ttm_bo_device_init(), so ttm uses it instead of its own embedded struct. This makes some gem functions (specifically drm_gem_object_lookup) work on ttm objects. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_ttm.c | 2 +- 1 file changed, 1 insertion(+),

Re: [PATCH net-next] vsock/virtio: a better comment on credit update

From: "Michael S. Tsirkin" Date: Tue, 3 Sep 2019 03:38:16 -0400 > The comment we have is just repeating what the code does. > Include the *reason* for the condition instead. > > Cc: Stefano Garzarella > Signed-off-by: Michael S. Tsirkin Applied.