search for: io_subchannel_initialize_dev

...nside 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 tries to get virtio config form within a cio > interrupt context we deadlock, because we try to take a lock we already have. > > That said, I don't think this limitation is by design (i.e. intended). > May...

...> > > > > 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 tries to get virtio config form within a cio > > > interrupt context we deadlock, because we try to take a lock we already have. > > > > > > That said, I don't think this limitatio...

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