From: Cornelia Huck <cohuck@redhat.com> To: "Michael S. Tsirkin" <mst@redhat.com>, Jason Wang <jasowang@redhat.com> Cc: linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, sgarzare@redhat.com, eperezma@redhat.com, lulu@redhat.com, tglx@linutronix.de, peterz@infradead.org, paulmck@kernel.org, maz@kernel.org, pasic@linux.ibm.com Subject: Re: [PATCH V3 6/9] virtio-ccw: implement synchronize_cbs() Date: Mon, 25 Apr 2022 10:54:24 +0200 [thread overview] Message-ID: <87a6c98rwf.fsf@redhat.com> (raw) In-Reply-To: <20220425040512-mutt-send-email-mst@kernel.org> On Mon, Apr 25 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote: > On Mon, Apr 25, 2022 at 10:44:15AM +0800, Jason Wang wrote: >> This patch tries to implement the synchronize_cbs() for ccw. For the >> vring_interrupt() that is called via virtio_airq_handler(), the >> synchronization is simply done via the airq_info's lock. For the >> vring_interrupt() that is called via virtio_ccw_int_handler(), a per >> device spinlock for irq is introduced ans used in the synchronization >> method. >> >> Cc: Thomas Gleixner <tglx@linutronix.de> >> Cc: Peter Zijlstra <peterz@infradead.org> >> Cc: "Paul E. McKenney" <paulmck@kernel.org> >> Cc: Marc Zyngier <maz@kernel.org> >> Cc: Halil Pasic <pasic@linux.ibm.com> >> Cc: Cornelia Huck <cohuck@redhat.com> >> Signed-off-by: Jason Wang <jasowang@redhat.com> > > > This is the only one that is giving me pause. Halil, Cornelia, > should we be concerned about the performance impact here? > Any chance it can be tested? We can have a bunch of devices using the same airq structure, and the sync cb creates a choke point, same as registering/unregistering. If invoking the sync cb is a rare operation (same as (un)registering), it should not affect interrupt processing for other devices too much, but it really should be rare. For testing, you would probably want to use a setup with many devices that share the same airq area (you can fit a lot of devices if they have few queues), generate traffic on the queues, and then do something that triggers the callback (adding/removing a new device in a loop?) I currently don't have such a setup handy; Halil, would you be able to test that? > >> --- >> drivers/s390/virtio/virtio_ccw.c | 27 +++++++++++++++++++++++++++ >> 1 file changed, 27 insertions(+) >> >> diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c >> index d35e7a3f7067..c19f07a82d62 100644 >> --- a/drivers/s390/virtio/virtio_ccw.c >> +++ b/drivers/s390/virtio/virtio_ccw.c >> @@ -62,6 +62,7 @@ struct virtio_ccw_device { >> unsigned int revision; /* Transport revision */ >> wait_queue_head_t wait_q; >> spinlock_t lock; >> + spinlock_t irq_lock; >> struct mutex io_lock; /* Serializes I/O requests */ >> struct list_head virtqueues; >> bool is_thinint; >> @@ -984,6 +985,27 @@ static const char *virtio_ccw_bus_name(struct virtio_device *vdev) >> return dev_name(&vcdev->cdev->dev); >> } >> >> +static void virtio_ccw_synchronize_cbs(struct virtio_device *vdev) >> +{ >> + struct virtio_ccw_device *vcdev = to_vc_device(vdev); >> + struct airq_info *info = vcdev->airq_info; >> + >> + /* >> + * Synchronize with the vring_interrupt() called by >> + * virtio_ccw_int_handler(). >> + */ >> + spin_lock(&vcdev->irq_lock); >> + spin_unlock(&vcdev->irq_lock); >> + >> + if (info) { >> + /* >> + * Synchronize with the vring_interrupt() with airq indicator >> + */ >> + write_lock(&info->lock); >> + write_unlock(&info->lock); >> + } I think we can make this an either/or operation (devices will either use classic interrupts or adapter interrupts)? >> +} >> + >> static const struct virtio_config_ops virtio_ccw_config_ops = { >> .get_features = virtio_ccw_get_features, >> .finalize_features = virtio_ccw_finalize_features,
WARNING: multiple messages have this Message-ID (diff)
From: Cornelia Huck <cohuck@redhat.com> To: "Michael S. Tsirkin" <mst@redhat.com>, Jason Wang <jasowang@redhat.com> Cc: paulmck@kernel.org, lulu@redhat.com, peterz@infradead.org, maz@kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, pasic@linux.ibm.com, eperezma@redhat.com, tglx@linutronix.de Subject: Re: [PATCH V3 6/9] virtio-ccw: implement synchronize_cbs() Date: Mon, 25 Apr 2022 10:54:24 +0200 [thread overview] Message-ID: <87a6c98rwf.fsf@redhat.com> (raw) In-Reply-To: <20220425040512-mutt-send-email-mst@kernel.org> On Mon, Apr 25 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote: > On Mon, Apr 25, 2022 at 10:44:15AM +0800, Jason Wang wrote: >> This patch tries to implement the synchronize_cbs() for ccw. For the >> vring_interrupt() that is called via virtio_airq_handler(), the >> synchronization is simply done via the airq_info's lock. For the >> vring_interrupt() that is called via virtio_ccw_int_handler(), a per >> device spinlock for irq is introduced ans used in the synchronization >> method. >> >> Cc: Thomas Gleixner <tglx@linutronix.de> >> Cc: Peter Zijlstra <peterz@infradead.org> >> Cc: "Paul E. McKenney" <paulmck@kernel.org> >> Cc: Marc Zyngier <maz@kernel.org> >> Cc: Halil Pasic <pasic@linux.ibm.com> >> Cc: Cornelia Huck <cohuck@redhat.com> >> Signed-off-by: Jason Wang <jasowang@redhat.com> > > > This is the only one that is giving me pause. Halil, Cornelia, > should we be concerned about the performance impact here? > Any chance it can be tested? We can have a bunch of devices using the same airq structure, and the sync cb creates a choke point, same as registering/unregistering. If invoking the sync cb is a rare operation (same as (un)registering), it should not affect interrupt processing for other devices too much, but it really should be rare. For testing, you would probably want to use a setup with many devices that share the same airq area (you can fit a lot of devices if they have few queues), generate traffic on the queues, and then do something that triggers the callback (adding/removing a new device in a loop?) I currently don't have such a setup handy; Halil, would you be able to test that? > >> --- >> drivers/s390/virtio/virtio_ccw.c | 27 +++++++++++++++++++++++++++ >> 1 file changed, 27 insertions(+) >> >> diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c >> index d35e7a3f7067..c19f07a82d62 100644 >> --- a/drivers/s390/virtio/virtio_ccw.c >> +++ b/drivers/s390/virtio/virtio_ccw.c >> @@ -62,6 +62,7 @@ struct virtio_ccw_device { >> unsigned int revision; /* Transport revision */ >> wait_queue_head_t wait_q; >> spinlock_t lock; >> + spinlock_t irq_lock; >> struct mutex io_lock; /* Serializes I/O requests */ >> struct list_head virtqueues; >> bool is_thinint; >> @@ -984,6 +985,27 @@ static const char *virtio_ccw_bus_name(struct virtio_device *vdev) >> return dev_name(&vcdev->cdev->dev); >> } >> >> +static void virtio_ccw_synchronize_cbs(struct virtio_device *vdev) >> +{ >> + struct virtio_ccw_device *vcdev = to_vc_device(vdev); >> + struct airq_info *info = vcdev->airq_info; >> + >> + /* >> + * Synchronize with the vring_interrupt() called by >> + * virtio_ccw_int_handler(). >> + */ >> + spin_lock(&vcdev->irq_lock); >> + spin_unlock(&vcdev->irq_lock); >> + >> + if (info) { >> + /* >> + * Synchronize with the vring_interrupt() with airq indicator >> + */ >> + write_lock(&info->lock); >> + write_unlock(&info->lock); >> + } I think we can make this an either/or operation (devices will either use classic interrupts or adapter interrupts)? >> +} >> + >> static const struct virtio_config_ops virtio_ccw_config_ops = { >> .get_features = virtio_ccw_get_features, >> .finalize_features = virtio_ccw_finalize_features, _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2022-04-25 8:55 UTC|newest] Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-25 2:44 [PATCH V3 0/9] rework on the IRQ hardening of virtio Jason Wang 2022-04-25 2:44 ` Jason Wang 2022-04-25 2:44 ` [PATCH V3 1/9] virtio: use virtio_device_ready() in virtio_device_restore() Jason Wang 2022-04-25 2:44 ` Jason Wang 2022-04-28 9:07 ` Cornelia Huck 2022-04-28 9:07 ` Cornelia Huck 2022-04-25 2:44 ` [PATCH V3 2/9] virtio: use virtio_reset_device() when possible Jason Wang 2022-04-25 2:44 ` Jason Wang 2022-04-28 9:07 ` Cornelia Huck 2022-04-28 9:07 ` Cornelia Huck 2022-04-25 2:44 ` [PATCH V3 3/9] virtio: introduce config op to synchronize vring callbacks Jason Wang 2022-04-25 2:44 ` Jason Wang 2022-04-28 9:13 ` Cornelia Huck 2022-04-28 9:13 ` Cornelia Huck 2022-04-29 2:08 ` Jason Wang 2022-04-29 2:08 ` Jason Wang 2022-04-29 7:25 ` Cornelia Huck 2022-04-29 7:25 ` Cornelia Huck 2022-05-05 8:15 ` Jason Wang 2022-05-05 8:15 ` Jason Wang 2022-04-25 2:44 ` [PATCH V3 4/9] virtio-pci: implement synchronize_cbs() Jason Wang 2022-04-25 2:44 ` Jason Wang 2022-04-25 2:44 ` [PATCH V3 5/9] virtio-mmio: " Jason Wang 2022-04-25 2:44 ` Jason Wang 2022-04-25 2:44 ` [PATCH V3 6/9] virtio-ccw: " Jason Wang 2022-04-25 2:44 ` Jason Wang 2022-04-25 8:08 ` Michael S. Tsirkin 2022-04-25 8:08 ` Michael S. Tsirkin 2022-04-25 8:54 ` Cornelia Huck [this message] 2022-04-25 8:54 ` Cornelia Huck 2022-04-25 13:59 ` Michael S. Tsirkin 2022-04-25 13:59 ` Michael S. Tsirkin 2022-04-26 2:29 ` Halil Pasic 2022-04-26 2:29 ` Halil Pasic 2022-04-26 3:35 ` Michael S. Tsirkin 2022-04-26 3:35 ` Michael S. Tsirkin 2022-04-26 3:38 ` Michael S. Tsirkin 2022-04-26 3:38 ` Michael S. Tsirkin 2022-04-26 3:42 ` Jason Wang 2022-04-26 3:42 ` Jason Wang 2022-04-26 3:53 ` Michael S. Tsirkin 2022-04-26 3:53 ` Michael S. Tsirkin 2022-04-26 3:55 ` Michael S. Tsirkin 2022-04-26 3:55 ` Michael S. Tsirkin 2022-04-26 4:07 ` Jason Wang 2022-04-26 4:07 ` Jason Wang 2022-04-26 6:30 ` Michael S. Tsirkin 2022-04-26 6:30 ` Michael S. Tsirkin 2022-04-27 3:53 ` Jason Wang 2022-04-27 3:53 ` Jason Wang 2022-04-27 6:28 ` Michael S. Tsirkin 2022-04-27 6:28 ` Michael S. Tsirkin 2022-04-27 6:30 ` Michael S. Tsirkin 2022-04-27 6:30 ` Michael S. Tsirkin 2022-04-27 7:57 ` Jason Wang 2022-04-27 7:57 ` Jason Wang 2022-04-27 15:15 ` Michael S. Tsirkin 2022-04-27 15:15 ` Michael S. Tsirkin 2022-04-26 15:47 ` Cornelia Huck 2022-04-26 15:47 ` Cornelia Huck 2022-04-26 16:43 ` Michael S. Tsirkin 2022-04-26 16:43 ` Michael S. Tsirkin 2022-04-27 9:27 ` Cornelia Huck 2022-04-27 9:27 ` Cornelia Huck 2022-04-28 2:43 ` Halil Pasic 2022-04-28 2:43 ` Halil Pasic 2022-04-28 3:04 ` Jason Wang 2022-04-28 3:04 ` Jason Wang 2022-04-28 5:24 ` Michael S. Tsirkin 2022-04-28 5:24 ` Michael S. Tsirkin 2022-04-28 5:51 ` Jason Wang 2022-04-28 5:51 ` Jason Wang 2022-04-28 5:55 ` Michael S. Tsirkin 2022-04-28 5:55 ` Michael S. Tsirkin 2022-04-28 6:02 ` Jason Wang 2022-04-28 6:02 ` Jason Wang 2022-04-28 6:17 ` Michael S. Tsirkin 2022-04-28 6:17 ` Michael S. Tsirkin 2022-04-28 7:42 ` Cornelia Huck 2022-04-28 7:42 ` Cornelia Huck 2022-04-29 2:02 ` Jason Wang 2022-04-29 2:02 ` Jason Wang 2022-04-28 4:12 ` Michael S. Tsirkin 2022-04-28 4:12 ` Michael S. Tsirkin 2022-04-26 2:50 ` Halil Pasic 2022-04-26 2:50 ` Halil Pasic 2022-04-26 3:46 ` Jason Wang 2022-04-26 3:46 ` Jason Wang [not found] ` <20220426053856.3325-1-hdanton@sina.com> 2022-04-26 5:59 ` Jason Wang 2022-04-25 2:44 ` [PATCH V3 7/9] virtio: allow to unbreak virtqueue Jason Wang 2022-04-25 2:44 ` Jason Wang 2022-04-25 12:44 ` Cornelia Huck 2022-04-25 12:44 ` Cornelia Huck 2022-04-25 14:04 ` Michael S. Tsirkin 2022-04-25 14:04 ` Michael S. Tsirkin 2022-04-26 3:45 ` Jason Wang 2022-04-26 3:45 ` Jason Wang 2022-04-25 2:44 ` [PATCH V3 8/9] virtio: harden vring IRQ Jason Wang 2022-04-25 2:44 ` Jason Wang 2022-04-25 2:44 ` [PATCH V3 9/9] virtio: use WARN_ON() to warning illegal status value Jason Wang 2022-04-25 2:44 ` Jason Wang 2022-04-25 2:49 ` [PATCH V3 0/9] rework on the IRQ hardening of virtio Jason Wang 2022-04-25 2:49 ` Jason Wang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87a6c98rwf.fsf@redhat.com \ --to=cohuck@redhat.com \ --cc=eperezma@redhat.com \ --cc=jasowang@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=lulu@redhat.com \ --cc=maz@kernel.org \ --cc=mst@redhat.com \ --cc=pasic@linux.ibm.com \ --cc=paulmck@kernel.org \ --cc=peterz@infradead.org \ --cc=sgarzare@redhat.com \ --cc=tglx@linutronix.de \ --cc=virtualization@lists.linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.