search for: ccw_device_start

...n interrupt > context. AFAICT this never worked. I'm not sure about "never worked". It seems to work well with virtio-pci. But looking forward to hearing a solid reason why reading config inside the handler is forbidden (if that's true). > About what happens. The apidoc of ccw_device_start() says it needs to be > called with the ccw device lock held, so ccw_io_helper() tries to take it (since > forever I guess). OTOH do_cio_interrupt() takes the subchannel lock and > io_subchannel_initialize_dev() makes the ccw device lock be the subchannel > lock. That means when one tri...

...t; @@ -296,6 +298,7 @@ static int ccw_io_helper(struct virtio_ccw_device *vcdev, > unsigned long flags; > int flag = intparm & VIRTIO_CCW_INTPARM_MASK; > > + mutex_lock(&vcio_mtx); > do { > spin_lock_irqsave(get_ccwdev_lock(vcdev->cdev), flags); > ret = ccw_device_start(vcdev->cdev, ccw, intparm, 0, 0); > @@ -308,7 +311,9 @@ static int ccw_io_helper(struct virtio_ccw_device *vcdev, > cpu_relax(); > } while (ret == -EBUSY); We probably still want to keep this while loop to be on the safe side (unsolicited status from the hypervisor, for example.)...

...de the handler is forbidden or not. So please > don't expect me providing the solid reasons you are looking forward to. It won't work with the current code, and this is all a bit ugly :( More verbose explanation below. > > > > > > About what happens. The apidoc of ccw_device_start() says it needs to be > > > called with the ccw device lock held, so ccw_io_helper() tries to take it (since > > > forever I guess). OTOH do_cio_interrupt() takes the subchannel lock and > > > io_subchannel_initialize_dev() makes the ccw device lock be the subchannel >...

The following changes since commit 8c0f9f5b309d627182d5da72a69246f58bde1026: Revert "uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name" (2018-09-25 13:28:58 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git tags/virtio-ccw-20180926 for you to fetch changes up to

Some vqs don't need to be allocated when the related feature bits are disabled. Callers notice the vq allocation layer by setting the related names[i] to be NULL. This patch series fixes the find_vqs implementations to handle this case. Wei Wang (2): virtio_pci: use queue idx instead of array idx to set up the vq virtio: don't allocate vqs when names[i] = NULL

Some vqs don't need to be allocated when the related feature bits are disabled. Callers notice the vq allocation layer by setting the related names[i] to be NULL. This patch series fixes the find_vqs implementations to handle this case. Wei Wang (2): virtio_pci: use queue idx instead of array idx to set up the vq virtio: don't allocate vqs when names[i] = NULL

...irtio_ccw_device *vcdev, struct ccw1 *ccw, __u32 intparm) { int ret; unsigned long flags; int flag = intparm & VIRTIO_CCW_INTPARM_MASK; do { spin_lock_irqsave(get_ccwdev_lock(vcdev->cdev), flags); ret = ccw_device_start(vcdev->cdev, ccw, intparm, 0, 0); if (!ret) { if (!vcdev->curr_io) vcdev->err = 0; vcdev->curr_io |= flag; } spin_unlock_irqrestore(get_ccwdev_lock(vcdev->c...

...irtio_ccw_device *vcdev, struct ccw1 *ccw, __u32 intparm) { int ret; unsigned long flags; int flag = intparm & VIRTIO_CCW_INTPARM_MASK; do { spin_lock_irqsave(get_ccwdev_lock(vcdev->cdev), flags); ret = ccw_device_start(vcdev->cdev, ccw, intparm, 0, 0); if (!ret) { if (!vcdev->curr_io) vcdev->err = 0; vcdev->curr_io |= flag; } spin_unlock_irqrestore(get_ccwdev_lock(vcdev->c...

On Mon, Mar 02, 2015 at 10:37:26AM +1030, Rusty Russell wrote: > Thomas Huth <thuth at linux.vnet.ibm.com> writes: > > On Thu, 26 Feb 2015 11:50:42 +1030 > > Rusty Russell <rusty at rustcorp.com.au> wrote: > > > >> Thomas Huth <thuth at linux.vnet.ibm.com> writes: > >> > Hi all, > >> > > >> > with the recent

On Mon, Mar 02, 2015 at 10:37:26AM +1030, Rusty Russell wrote: > Thomas Huth <thuth at linux.vnet.ibm.com> writes: > > On Thu, 26 Feb 2015 11:50:42 +1030 > > Rusty Russell <rusty at rustcorp.com.au> wrote: > > > >> Thomas Huth <thuth at linux.vnet.ibm.com> writes: > >> > Hi all, > >> > > >> > with the recent