Re: [PATCH] drm/cirrus: remove leftover files

2019-05-23 Thread Gerd Hoffmann
On Wed, May 22, 2019 at 05:06:34PM +0200, Sam Ravnborg wrote: > On Wed, May 22, 2019 at 12:33:07PM +0200, Gerd Hoffmann wrote: > > cirrus_drv.h and cirrus_ttm.c are unused since commit ab3e023b1b4c > > ("drm/cirrus: rewrite and modernize driver"), apparently I ran "rm" > > instead of "git rm" on th

Re: [PATCH 2/4] drm/virtio: remove irrelevant DRM_UNLOCKED flag

2019-05-23 Thread Gerd Hoffmann
On Wed, May 22, 2019 at 04:47:00PM +0100, Emil Velikov wrote: > From: Emil Velikov > > DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it. Patch applied to drm-misc-next. thanks, Gerd ___ Virtualization mailing list Virtualization@l

Re: [Qemu-devel] custom virt-io support (in user-mode-linux)

2019-05-23 Thread Stefan Hajnoczi
On Wed, May 22, 2019 at 03:02:38PM +0200, Johannes Berg wrote: > Hi, > > While my main interest is mostly in UML right now [1] I've CC'ed the > qemu and virtualization lists because something similar might actually > apply to other types of virtualization. > > I'm thinking about adding virt-io su

Re: [Qemu-devel] custom virt-io support (in user-mode-linux)

2019-05-23 Thread Johannes Berg
Hi Stefan, > Check out vhost-user. It's a protocol for running a subset of a VIRTIO > device's emulation in a separate process (usually just the data plane > with the PCI emulation and other configuration/setup still handled by > QEMU). Yes, I think that's basically what I'm looking for. > vhos

Re: [Qemu-devel] custom virt-io support (in user-mode-linux)

2019-05-23 Thread Stefan Hajnoczi
On Thu, May 23, 2019 at 3:25 PM Johannes Berg wrote: > Not sure I understand why there's all this stuff about multiple FDs, > once you have access to the guest's memory, why do you still need a > second (or more) FDs? The memory regions could be different files (maybe additional RAM was hotplugge

Re: [PATCH] virtio/virtio_ring: do some comment fixes

2019-05-23 Thread Stefan Hajnoczi
On Sun, May 19, 2019 at 5:17 PM Jiang Biao wrote: > > There are lots of mismatches between comments and codes, this > patch do these comment fixes. > > Signed-off-by: Jiang Biao > --- > drivers/virtio/virtio_ring.c | 27 ++- > 1 file changed, 14 insertions(+), 13 deletion

Re: [PATCH 05/10] s390/cio: introduce DMA pools to cio

2019-05-23 Thread Halil Pasic
On Wed, 8 May 2019 15:18:10 +0200 (CEST) Sebastian Ott wrote: > > @@ -224,6 +228,9 @@ struct subchannel *css_alloc_subchannel(struct > > subchannel_id schid, > > INIT_WORK(&sch->todo_work, css_sch_todo); > > sch->dev.release = &css_subchannel_release; > > device_initialize(&sch->dev)

[PATCH v2 1/8] s390/mm: force swiotlb for protected virtualization

2019-05-23 Thread Michael Mueller
From: Halil Pasic On s390, protected virtualization guests have to use bounced I/O buffers. That requires some plumbing. Let us make sure, any device that uses DMA API with direct ops correctly is spared from the problems, that a hypervisor attempting I/O to a non-shared page would bring. Sign

[PATCH v2 2/8] s390/cio: introduce DMA pools to cio

2019-05-23 Thread Michael Mueller
From: Halil Pasic To support protected virtualization cio will need to make sure the memory used for communication with the hypervisor is DMA memory. Let us introduce one global cio, and some tools for pools seated at individual devices. Our DMA pools are implemented as a gen_pool backed with D

[PATCH v2 3/8] s390/cio: add basic protected virtualization support

2019-05-23 Thread Michael Mueller
From: Halil Pasic As virtio-ccw devices are channel devices, we need to use the dma area for any communication with the hypervisor. It handles neither QDIO in the common code, nor any device type specific stuff (like channel programs constructed by the DASD driver). An interesting side effect i

[PATCH v2 0/8] s390: virtio: support protected virtualization

2019-05-23 Thread Michael Mueller
Enhanced virtualization protection technology may require the use of bounce buffers for I/O. While support for this was built into the virtio core, virtio-ccw wasn't changed accordingly. Some background on technology (not part of this series) and the terminology used. * Protected Virtualization (

[PATCH v2 4/8] s390/airq: use DMA memory for adapter interrupts

2019-05-23 Thread Michael Mueller
From: Halil Pasic Protected virtualization guests have to use shared pages for airq notifier bit vectors, because hypervisor needs to write these bits. Let us make sure we allocate DMA memory for the notifier bit vectors by replacing the kmem_cache with a dma_cache and kalloc() with cio_dma_zall

[PATCH v2 5/8] virtio/s390: use cacheline aligned airq bit vectors

2019-05-23 Thread Michael Mueller
From: Halil Pasic The flag AIRQ_IV_CACHELINE was recently added to airq_iv_create(). Let us use it! We actually wanted the vector to span a cacheline all along. Signed-off-by: Halil Pasic --- drivers/s390/virtio/virtio_ccw.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a

[PATCH v2 8/8] virtio/s390: make airq summary indicators DMA

2019-05-23 Thread Michael Mueller
From: Halil Pasic Hypervisor needs to interact with the summary indicators, so these need to be DMA memory as well (at least for protected virtualization guests). Signed-off-by: Halil Pasic --- drivers/s390/virtio/virtio_ccw.c | 22 +++--- 1 file changed, 15 insertions(+), 7 de

[PATCH v2 7/8] virtio/s390: use DMA memory for ccw I/O and classic notifiers

2019-05-23 Thread Michael Mueller
From: Halil Pasic Before virtio-ccw could get away with not using DMA API for the pieces of memory it does ccw I/O with. With protected virtualization this has to change, since the hypervisor needs to read and sometimes also write these pieces of memory. The hypervisor is supposed to poke the cl

[PATCH v2 6/8] virtio/s390: add indirection to indicators access

2019-05-23 Thread Michael Mueller
From: Halil Pasic This will come in handy soon when we pull out the indicators from virtio_ccw_device to a memory area that is shared with the hypervisor (in particular for protected virtualization guests). Signed-off-by: Halil Pasic Reviewed-by: Pierre Morel --- drivers/s390/virtio/virtio_cc

Re: [PATCH V2 0/4] Prevent vhost kthread from hogging CPU

2019-05-23 Thread Michael S. Tsirkin
On Sat, May 18, 2019 at 01:27:12PM -0700, David Miller wrote: > From: Jason Wang > Date: Fri, 17 May 2019 00:29:48 -0400 > > > Hi: > > > > This series try to prevent a guest triggerable CPU hogging through > > vhost kthread. This is done by introducing and checking the weight > > after each requ

[PATCH 4.9 07/53] vsock/virtio: Initialize core virtio vsock before registering the driver

2019-05-23 Thread Greg Kroah-Hartman
From: "Jorge E. Moreira" [ Upstream commit ba95e5dfd36647622d8897a2a0470dde60e59ffd ] Avoid a race in which static variables in net/vmw_vsock/af_vsock.c are accessed (while handling interrupts) before they are initialized. [4.201410] BUG: unable to handle kernel paging request at ff

[PATCH 4.14 09/77] vsock/virtio: Initialize core virtio vsock before registering the driver

2019-05-23 Thread Greg Kroah-Hartman
From: "Jorge E. Moreira" [ Upstream commit ba95e5dfd36647622d8897a2a0470dde60e59ffd ] Avoid a race in which static variables in net/vmw_vsock/af_vsock.c are accessed (while handling interrupts) before they are initialized. [4.201410] BUG: unable to handle kernel paging request at ff

[PATCH 4.19 014/114] vsock/virtio: Initialize core virtio vsock before registering the driver

2019-05-23 Thread Greg Kroah-Hartman
From: "Jorge E. Moreira" [ Upstream commit ba95e5dfd36647622d8897a2a0470dde60e59ffd ] Avoid a race in which static variables in net/vmw_vsock/af_vsock.c are accessed (while handling interrupts) before they are initialized. [4.201410] BUG: unable to handle kernel paging request at ff

[PATCH 5.0 014/139] vsock/virtio: Initialize core virtio vsock before registering the driver

2019-05-23 Thread Greg Kroah-Hartman
From: "Jorge E. Moreira" [ Upstream commit ba95e5dfd36647622d8897a2a0470dde60e59ffd ] Avoid a race in which static variables in net/vmw_vsock/af_vsock.c are accessed (while handling interrupts) before they are initialized. [4.201410] BUG: unable to handle kernel paging request at ff

[PATCH 5.1 019/122] vsock/virtio: Initialize core virtio vsock before registering the driver

2019-05-23 Thread Greg Kroah-Hartman
From: "Jorge E. Moreira" [ Upstream commit ba95e5dfd36647622d8897a2a0470dde60e59ffd ] Avoid a race in which static variables in net/vmw_vsock/af_vsock.c are accessed (while handling interrupts) before they are initialized. [4.201410] BUG: unable to handle kernel paging request at ff