search for: cdevs

As virtio-ccw devices are channel devices, we need to use the dma area for any communication with the hypervisor. This patch addresses the most basic stuff (mostly what is required for virtio-ccw), and does take care of QDIO or any devices. An interesting side effect is that virtio structures are now going to get allocated in 31 bit addressable storage. Signed-off-by: Halil Pasic <pasic at

From: Halil Pasic <pasic at linux.ibm.com> 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 is that virtio structures are now going to get allocated in 31 bit

From: Halil Pasic <pasic at linux.ibm.com> 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 is that virtio structures are now going to get allocated in 31 bit

As virtio-ccw devices are channel devices, we need to use the dma area within the common I/O layer for any communication with the hypervisor. Note that we do not need to use that area for control blocks directly referenced by instructions, e.g. the orb. It handles neither QDIO in the common code, nor any device type specific stuff (like channel programs constructed by the DASD driver). An

On Thu, 23 May 2019, Michael Mueller wrote: > static struct ccw_device * io_subchannel_allocate_dev(struct subchannel *sch) > { > struct ccw_device *cdev; > + struct gen_pool *dma_pool; > > cdev = kzalloc(sizeof(*cdev), GFP_KERNEL); > - if (cdev) { > - cdev->private = kzalloc(sizeof(struct ccw_device_private), > - GFP_KERNEL | GFP_DMA); > - if

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 (PV): Protected Virtualization guarantees, that non-shared memory of a guest that operates in PV

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 (PV): Protected Virtualization guarantees, that non-shared memory of a guest that operates in PV

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 (PV): Protected Virtualization guarantees, that non-shared memory of a guest that operates in PV

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 (PV): Protected Virtualization guarantees, that non-shared memory of a guest that operates in PV

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 (PV): Protected Virtualization guarantees, that non-shared memory of a guest that operates in PV

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 (PV): Protected Virtualization guarantees, that non-shared memory of a guest that operates in PV

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 (PV): Protected Virtualization guarantees, that non-shared memory of a guest that operates in PV

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 (PV): Protected Virtualization guarantees, that non-shared memory of a guest that operates in PV

The interrupt handler virtio_ccw_int_handler() using the vcdev pointer is protected by the ccw_device lock. Resetting the pointer within the ccw_device structure should be done when holding this lock. Also resetting the vcdev pointer (under the ccw_device lock) prior to freeing the vcdev pointer memory removes a critical path. Signed-off-by: Heinz Graalfs <graalfs at linux.vnet.ibm.com>

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 classic notifiers, if these are used, out of band with regards to ccw I/O. So these need to be allocated as DMA memory

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 classic notifiers, if these are used, out of band with regards to ccw I/O. So these need to be allocated as DMA memory

When a device is lost, the common I/O layer calls the notification handler with CIO_GONE: In that event, flag device_lost as true. In case the device had been flagged as lost when the remove/offline callbacks are called, call the new virtio_break_device() function prior to invoking device_unregister(). This avoids hangs of I/O triggered via the device unregistration callbacks. Signed-off-by:

Rusty, this patch exploits the new function virtio_break_device() as of your patch set dated January 15th on linux-kernel at vger.kernel.org. The patch avoids hang situations during device unregister, when a (block) device with active IO is hot-unplugged. Heinz Graalfs (1): virtio_ccw: introduce device_lost in virtio_ccw_device drivers/s390/kvm/virtio_ccw.c | 49

Rusty, this patch exploits the new function virtio_break_device() as of your patch set dated January 15th on linux-kernel at vger.kernel.org. The patch avoids hang situations during device unregister, when a (block) device with active IO is hot-unplugged. Heinz Graalfs (1): virtio_ccw: introduce device_lost in virtio_ccw_device drivers/s390/kvm/virtio_ccw.c | 49

On Wed, Apr 3, 2019 at 9:23 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > Time to kill some bad sample code people are copying from ;) > > This is a complete rewrite of the cirrus driver. The cirrus_mode_set() > function is pretty much the only function which is carried over largely > unmodified. Everything else is upside down. > > It is a single monster patch.