On Tue, May 10, 2022 at 7:32 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > On Sat, May 07, 2022 at 03:19:53PM +0800, Jason Wang wrote: > > This is a rework on the previous IRQ hardening that is done for > > virtio-pci where several drawbacks were found and were reverted: > > > > 1) try to use IRQF_NO_AUTOEN which is not friendly to affinity managed IRQ > > that is used by some device such as virtio-blk > > 2) done only for PCI transport > > > > The vq->broken is re-used in this patch for implementing the IRQ > > hardening. The vq->broken is set to true during both initialization > > and reset. And the vq->broken is set to false in > > virtio_device_ready(). Then vring_interrupt can check and return when > > vq->broken is true. And in this case, switch to return IRQ_NONE to let > > the interrupt core aware of such invalid interrupt to prevent IRQ > > storm. > > > > The reason of using a per queue variable instead of a per device one > > is that we may need it for per queue reset hardening in the future. > > > > Note that the hardening is only done for vring interrupt since the > > config interrupt hardening is already done in commit 22b7050a024d7 > > ("virtio: defer config changed notifications"). But the method that is > > used by config interrupt can't be reused by the vring interrupt > > handler because it uses spinlock to do the synchronization which is > > expensive. > > > > Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > > Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx> > > Cc: "Paul E. McKenney" <paulmck@xxxxxxxxxx> > > Cc: Marc Zyngier <maz@xxxxxxxxxx> > > Cc: Halil Pasic <pasic@xxxxxxxxxxxxx> > > Cc: Cornelia Huck <cohuck@xxxxxxxxxx> > > Signed-off-by: Jason Wang <jasowang@xxxxxxxxxx> > > --- > > drivers/virtio/virtio.c | 15 ++++++++++++--- > > drivers/virtio/virtio_ring.c | 11 +++++++---- > > include/linux/virtio_config.h | 12 ++++++++++++ > > 3 files changed, 31 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c > > index 8dde44ea044a..696f5ba4f38e 100644 > > --- a/drivers/virtio/virtio.c > > +++ b/drivers/virtio/virtio.c > > @@ -220,6 +220,15 @@ static int virtio_features_ok(struct virtio_device *dev) > > * */ > > void virtio_reset_device(struct virtio_device *dev) > > { > > + /* > > + * The below virtio_synchronize_cbs() guarantees that any > > + * interrupt for this line arriving after > > + * virtio_synchronize_vqs() has completed is guaranteed to see > > + * driver_ready == false. > > + */ > > + virtio_break_device(dev); > > + virtio_synchronize_cbs(dev); > > + > > dev->config->reset(dev); > > } > > EXPORT_SYMBOL_GPL(virtio_reset_device); > > @@ -428,6 +437,9 @@ int register_virtio_device(struct virtio_device *dev) > > dev->config_enabled = false; > > dev->config_change_pending = false; > > > > + INIT_LIST_HEAD(&dev->vqs); > > + spin_lock_init(&dev->vqs_list_lock); > > + > > /* We always start by resetting the device, in case a previous > > * driver messed it up. This also tests that code path a little. */ > > virtio_reset_device(dev); > > @@ -435,9 +447,6 @@ int register_virtio_device(struct virtio_device *dev) > > /* Acknowledge that we've seen the device. */ > > virtio_add_status(dev, VIRTIO_CONFIG_S_ACKNOWLEDGE); > > > > - INIT_LIST_HEAD(&dev->vqs); > > - spin_lock_init(&dev->vqs_list_lock); > > - > > /* > > * device_add() causes the bus infrastructure to look for a matching > > * driver. > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > index 5b7df7c455f0..9dfad2890d7a 100644 > > --- a/drivers/virtio/virtio_ring.c > > +++ b/drivers/virtio/virtio_ring.c > > @@ -1690,7 +1690,7 @@ static struct virtqueue *vring_create_virtqueue_packed( > > vq->we_own_ring = true; > > vq->notify = notify; > > vq->weak_barriers = weak_barriers; > > - vq->broken = false; > > + vq->broken = true; > > vq->last_used_idx = 0; > > vq->event_triggered = false; > > vq->num_added = 0; > > @@ -2136,8 +2136,11 @@ irqreturn_t vring_interrupt(int irq, void *_vq) > > return IRQ_NONE; > > } > > > > - if (unlikely(vq->broken)) > > - return IRQ_HANDLED; > > + if (unlikely(vq->broken)) { > > + dev_warn_once(&vq->vq.vdev->dev, > > + "virtio vring IRQ raised before DRIVER_OK"); > > + return IRQ_NONE; > > + } > > > > /* Just a hint for performance: so it's ok that this can be racy! */ > > if (vq->event) > > @@ -2179,7 +2182,7 @@ struct virtqueue *__vring_new_virtqueue(unsigned int index, > > vq->we_own_ring = false; > > vq->notify = notify; > > vq->weak_barriers = weak_barriers; > > - vq->broken = false; > > + vq->broken = true; > > vq->last_used_idx = 0; > > vq->event_triggered = false; > > vq->num_added = 0; > > diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h > > index d8a2340f928e..23f1694cdbd5 100644 > > --- a/include/linux/virtio_config.h > > +++ b/include/linux/virtio_config.h > > @@ -256,6 +256,18 @@ void virtio_device_ready(struct virtio_device *dev) > > unsigned status = dev->config->get_status(dev); > > > > BUG_ON(status & VIRTIO_CONFIG_S_DRIVER_OK); > > + > > + /* > > + * The virtio_synchronize_cbs() makes sure vring_interrupt() > > + * will see the driver specific setup if it sees vq->broken > > + * as false. > > + */ > > + virtio_synchronize_cbs(dev); > > since you mention vq->broken above, maybe add > "set vq->broken to false" Ok. > > > + __virtio_unbreak_device(dev); > > + /* > > + * The transport is expected ensure the visibility of > > to ensure Will fix. > > > + * vq->broken > > let's add: "visibility by vq callbacks" Sure. > > > before setting VIRTIO_CONFIG_S_DRIVER_OK. > > + */ > > > Can I see some analysis of existing transports showing > this is actually the case for them? Yes. > And maybe add a comment near set_status to document the > requirement. For PCI and MMIO, we can quote the memory-barriers.txt or explain that wmb() is not needed before the MMIO writel(). For CCW, it looks not obvious, it looks to me the IO was submitted via __ssch() which has an inline assembly. Cornelia and Hali, could you help me to understand if and how did virtio_ccw_set_status() can ensure the visibility of the previous driver setup and vq->broken here? Thanks > > > dev->config->set_status(dev, status | VIRTIO_CONFIG_S_DRIVER_OK); > > } > > > > -- > > 2.25.1 > _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization