All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Halil Pasic <pasic@linux.ibm.com>,
	Cornelia Huck <cohuck@redhat.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Marc Zyngier <maz@kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	virtualization <virtualization@lists.linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH V2 4/5] virtio-pci: implement synchronize_vqs()
Date: Mon, 11 Apr 2022 16:22:19 +0800	[thread overview]
Message-ID: <CACGkMEtarZb6g3ij5=+As17+d9jtdAqNa1EzSuTXc7Pq_som0Q@mail.gmail.com> (raw)
In-Reply-To: <20220410034556-mutt-send-email-mst@kernel.org>

On Sun, Apr 10, 2022 at 3:51 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Fri, Apr 08, 2022 at 03:03:07PM +0200, Halil Pasic wrote:
> > On Wed, 06 Apr 2022 15:04:32 +0200
> > Cornelia Huck <cohuck@redhat.com> wrote:
> >
> > > On Wed, Apr 06 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > >
> > > > On Wed, Apr 06, 2022 at 04:35:37PM +0800, Jason Wang wrote:
> > > >> This patch implements PCI version of synchronize_vqs().
> > > >>
> > > >> 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>
> > > >> Signed-off-by: Jason Wang <jasowang@redhat.com>
> > > >
> > > > Please add implementations at least for ccw and mmio.
> > >
> > > I'm not sure what (if anything) can/should be done for ccw...
> >
> > If nothing needs to be done I would like to have at least a comment in
> > the code that explains why. So that somebody who reads the code
> > doesn't wonder: why is virtio-ccw not implementing that callback.
>
> Right.
>
> I am currently thinking instead of making this optional in the
> core we should make it mandatory, and have transports which do not
> need to sync have an empty stub with documentation explaining why.
>
> Also, do we want to document this sync is explicitly for irq enable/disable?
> synchronize_irq_enable_disable?

I would not since the transport is not guaranteed to use an interrupt
for callbacks.

>
>
> > >
> > > >
> > > >> ---
> > > >>  drivers/virtio/virtio_pci_common.c | 14 ++++++++++++++
> > > >>  drivers/virtio/virtio_pci_common.h |  2 ++
> > > >>  drivers/virtio/virtio_pci_legacy.c |  1 +
> > > >>  drivers/virtio/virtio_pci_modern.c |  2 ++
> > > >>  4 files changed, 19 insertions(+)
> > > >>
> > > >> diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c
> > > >> index d724f676608b..b78c8bc93a97 100644
> > > >> --- a/drivers/virtio/virtio_pci_common.c
> > > >> +++ b/drivers/virtio/virtio_pci_common.c
> > > >> @@ -37,6 +37,20 @@ void vp_synchronize_vectors(struct virtio_device *vdev)
> > > >>                  synchronize_irq(pci_irq_vector(vp_dev->pci_dev, i));
> > > >>  }
> > > >>
> > > >> +void vp_synchronize_vqs(struct virtio_device *vdev)
> > > >> +{
> > > >> +        struct virtio_pci_device *vp_dev = to_vp_device(vdev);
> > > >> +        int i;
> > > >> +
> > > >> +        if (vp_dev->intx_enabled) {
> > > >> +                synchronize_irq(vp_dev->pci_dev->irq);
> > > >> +                return;
> > > >> +        }
> > > >> +
> > > >> +        for (i = 0; i < vp_dev->msix_vectors; ++i)
> > > >> +                synchronize_irq(pci_irq_vector(vp_dev->pci_dev, i));
> > > >> +}
> > > >> +
> > >
> > > ...given that this seems to synchronize threaded interrupt handlers?
> > > Halil, do you think ccw needs to do anything? (AFAICS, we only have one
> > > 'irq' for channel devices anyway, and the handler just calls the
> > > relevant callbacks directly.)
> >
> > Sorry I don't understand enough yet. A more verbose documentation on
> > "virtio_synchronize_vqs - synchronize with virtqueue callbacks" would
> > surely benefit me. It may be more than enough for a back-belt but it
> > ain't enough for me to tell what is the callback supposed to accomplish.
> >
> > I will have to study this discussion and the code more thoroughly.
> > Tentatively I side with Jason and Michael in a sense, that I don't
> > believe virtio-ccw is safe against rough interrupts.

That's my feeling as well.

Thanks

> >
> > Sorry for the late response. I intend to revisit this on Monday. If
> > I don't please feel encouraged to ping.
> >
> > Regards,
> > Halil
>


WARNING: multiple messages have this Message-ID (diff)
From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Marc Zyngier <maz@kernel.org>, Cornelia Huck <cohuck@redhat.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	virtualization <virtualization@lists.linux-foundation.org>,
	Halil Pasic <pasic@linux.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH V2 4/5] virtio-pci: implement synchronize_vqs()
Date: Mon, 11 Apr 2022 16:22:19 +0800	[thread overview]
Message-ID: <CACGkMEtarZb6g3ij5=+As17+d9jtdAqNa1EzSuTXc7Pq_som0Q@mail.gmail.com> (raw)
In-Reply-To: <20220410034556-mutt-send-email-mst@kernel.org>

On Sun, Apr 10, 2022 at 3:51 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Fri, Apr 08, 2022 at 03:03:07PM +0200, Halil Pasic wrote:
> > On Wed, 06 Apr 2022 15:04:32 +0200
> > Cornelia Huck <cohuck@redhat.com> wrote:
> >
> > > On Wed, Apr 06 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > >
> > > > On Wed, Apr 06, 2022 at 04:35:37PM +0800, Jason Wang wrote:
> > > >> This patch implements PCI version of synchronize_vqs().
> > > >>
> > > >> 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>
> > > >> Signed-off-by: Jason Wang <jasowang@redhat.com>
> > > >
> > > > Please add implementations at least for ccw and mmio.
> > >
> > > I'm not sure what (if anything) can/should be done for ccw...
> >
> > If nothing needs to be done I would like to have at least a comment in
> > the code that explains why. So that somebody who reads the code
> > doesn't wonder: why is virtio-ccw not implementing that callback.
>
> Right.
>
> I am currently thinking instead of making this optional in the
> core we should make it mandatory, and have transports which do not
> need to sync have an empty stub with documentation explaining why.
>
> Also, do we want to document this sync is explicitly for irq enable/disable?
> synchronize_irq_enable_disable?

I would not since the transport is not guaranteed to use an interrupt
for callbacks.

>
>
> > >
> > > >
> > > >> ---
> > > >>  drivers/virtio/virtio_pci_common.c | 14 ++++++++++++++
> > > >>  drivers/virtio/virtio_pci_common.h |  2 ++
> > > >>  drivers/virtio/virtio_pci_legacy.c |  1 +
> > > >>  drivers/virtio/virtio_pci_modern.c |  2 ++
> > > >>  4 files changed, 19 insertions(+)
> > > >>
> > > >> diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c
> > > >> index d724f676608b..b78c8bc93a97 100644
> > > >> --- a/drivers/virtio/virtio_pci_common.c
> > > >> +++ b/drivers/virtio/virtio_pci_common.c
> > > >> @@ -37,6 +37,20 @@ void vp_synchronize_vectors(struct virtio_device *vdev)
> > > >>                  synchronize_irq(pci_irq_vector(vp_dev->pci_dev, i));
> > > >>  }
> > > >>
> > > >> +void vp_synchronize_vqs(struct virtio_device *vdev)
> > > >> +{
> > > >> +        struct virtio_pci_device *vp_dev = to_vp_device(vdev);
> > > >> +        int i;
> > > >> +
> > > >> +        if (vp_dev->intx_enabled) {
> > > >> +                synchronize_irq(vp_dev->pci_dev->irq);
> > > >> +                return;
> > > >> +        }
> > > >> +
> > > >> +        for (i = 0; i < vp_dev->msix_vectors; ++i)
> > > >> +                synchronize_irq(pci_irq_vector(vp_dev->pci_dev, i));
> > > >> +}
> > > >> +
> > >
> > > ...given that this seems to synchronize threaded interrupt handlers?
> > > Halil, do you think ccw needs to do anything? (AFAICS, we only have one
> > > 'irq' for channel devices anyway, and the handler just calls the
> > > relevant callbacks directly.)
> >
> > Sorry I don't understand enough yet. A more verbose documentation on
> > "virtio_synchronize_vqs - synchronize with virtqueue callbacks" would
> > surely benefit me. It may be more than enough for a back-belt but it
> > ain't enough for me to tell what is the callback supposed to accomplish.
> >
> > I will have to study this discussion and the code more thoroughly.
> > Tentatively I side with Jason and Michael in a sense, that I don't
> > believe virtio-ccw is safe against rough interrupts.

That's my feeling as well.

Thanks

> >
> > Sorry for the late response. I intend to revisit this on Monday. If
> > I don't please feel encouraged to ping.
> >
> > Regards,
> > Halil
>

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2022-04-11  8:22 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-06  8:35 [PATCH V2 0/5] rework on the IRQ hardening of virtio Jason Wang
2022-04-06  8:35 ` Jason Wang
2022-04-06  8:35 ` [PATCH V2 1/5] virtio: use virtio_device_ready() in virtio_device_restore() Jason Wang
2022-04-06  8:35   ` Jason Wang
2022-04-06 11:44   ` Michael S. Tsirkin
2022-04-06 11:44     ` Michael S. Tsirkin
2022-04-07  6:19     ` Jason Wang
2022-04-07  6:19       ` Jason Wang
2022-04-06  8:35 ` [PATCH V2 2/5] virtio: use virtio_reset_device() when possible Jason Wang
2022-04-06  8:35   ` Jason Wang
2022-04-06 11:53   ` Michael S. Tsirkin
2022-04-06 11:53     ` Michael S. Tsirkin
2022-04-06  8:35 ` [PATCH V2 3/5] virtio: introduce config op to synchronize vring callbacks Jason Wang
2022-04-06  8:35   ` Jason Wang
2022-04-06 11:59   ` Michael S. Tsirkin
2022-04-06 11:59     ` Michael S. Tsirkin
2022-04-07  6:25     ` Jason Wang
2022-04-07  6:25       ` Jason Wang
2022-04-06  8:35 ` [PATCH V2 4/5] virtio-pci: implement synchronize_vqs() Jason Wang
2022-04-06  8:35   ` Jason Wang
2022-04-06 12:00   ` Michael S. Tsirkin
2022-04-06 12:00     ` Michael S. Tsirkin
2022-04-06 13:04     ` Cornelia Huck
2022-04-06 13:04       ` Cornelia Huck
2022-04-06 15:31       ` Michael S. Tsirkin
2022-04-06 15:31         ` Michael S. Tsirkin
2022-04-07  6:38         ` Jason Wang
2022-04-07  6:38           ` Jason Wang
2022-04-07  7:52           ` Cornelia Huck
2022-04-07  7:52             ` Cornelia Huck
2022-04-07  8:04             ` Jason Wang
2022-04-07  8:04               ` Jason Wang
2022-04-08 13:03       ` Halil Pasic
2022-04-08 13:03         ` Halil Pasic
2022-04-10  7:51         ` Michael S. Tsirkin
2022-04-10  7:51           ` Michael S. Tsirkin
2022-04-11  8:22           ` Jason Wang [this message]
2022-04-11  8:22             ` Jason Wang
2022-04-11  8:56             ` Michael S. Tsirkin
2022-04-11  8:56               ` Michael S. Tsirkin
2022-04-12  2:21               ` Jason Wang
2022-04-12  2:21                 ` Jason Wang
2022-04-11 14:27             ` Cornelia Huck
2022-04-11 14:27               ` Cornelia Huck
2022-04-12  0:01               ` Halil Pasic
2022-04-12  0:01                 ` Halil Pasic
2022-04-12  2:24                 ` Jason Wang
2022-04-12  2:24                   ` Jason Wang
2022-04-12  7:55                   ` Halil Pasic
2022-04-12  7:55                     ` Halil Pasic
2022-04-12 16:48                 ` Cornelia Huck
2022-04-12 16:48                   ` Cornelia Huck
2022-04-13  2:53                   ` Jason Wang
2022-04-13  2:53                     ` Jason Wang
2022-04-13  6:41                     ` Cornelia Huck
2022-04-13  6:41                       ` Cornelia Huck
2022-04-06  8:35 ` [PATCH V2 5/5] virtio: harden vring IRQ Jason Wang
2022-04-06  8:35   ` Jason Wang
2022-04-06 12:04   ` Michael S. Tsirkin
2022-04-06 12:04     ` Michael S. Tsirkin
2022-04-07  6:39     ` Jason Wang
2022-04-07  6:39       ` Jason Wang
2022-04-06 11:36 ` [PATCH V2 0/5] rework on the IRQ hardening of virtio Michael S. Tsirkin
2022-04-06 11:36   ` Michael S. Tsirkin
2022-04-07  6:12   ` Jason Wang
2022-04-07  6:12     ` 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='CACGkMEtarZb6g3ij5=+As17+d9jtdAqNa1EzSuTXc7Pq_som0Q@mail.gmail.com' \
    --to=jasowang@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=mst@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --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: link
Be 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.