virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Jason Wang <jasowang@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
	peterz@infradead.org, maz@kernel.org,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Halil Pasic <pasic@linux.ibm.com>,
	tglx@linutronix.de
Subject: Re: [PATCH V2 4/5] virtio-pci: implement synchronize_vqs()
Date: Thu, 07 Apr 2022 09:52:59 +0200	[thread overview]
Message-ID: <87r169ba90.fsf@redhat.com> (raw)
In-Reply-To: <7e99abbf-f68d-4aa5-71b6-9d1d71b2d25b@redhat.com>

On Thu, Apr 07 2022, Jason Wang <jasowang@redhat.com> wrote:

> 在 2022/4/6 下午11:31, Michael S. Tsirkin 写道:
>> On Wed, Apr 06, 2022 at 03:04:32PM +0200, Cornelia Huck 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...
>>>
>>>>> ---
>>>>>   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?
>> No, any handlers at all. The point is to make sure any memory changes
>> made prior to this op are visible to callbacks.
>>
>> Jason, maybe add that to the documentation?
>
>
> Sure.
>
>
>>
>>> 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.)
>> Then you need to synchronize with that.
>
>
> Have a quick glance at the codes, it looks to me we can synchronize with 
> the IO_INTERRUPT. (Assuming all callbacks are triggered via 
> ccw_device_irq()).

Not quite, adapter interrupts are device-independent, but they are
relevant for vring interrupts.

That would mean that we would need to synchronize _all_ channel I/O
interrupts, which looks like a huge hammer. But do we really need that
at all?

The last patch in this series seems to be concerned with the "no vring
interrupts if the device is not ready" case, so it needs to synchronize
vring interrupts with device reset and setting the device status to
ready. For virtio-ccw, both reset and setting the status are channel I/O
operations, i.e. starting a program and waiting for the final device
interrupt for it, so synchronization (on a device level) is already
happening in a way. So I'm not sure if any extra synchronization is
actually needed in this case, but maybe I'm misunderstanding.

Do you have further use cases in mind?

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

  reply	other threads:[~2022-04-07  7:53 UTC|newest]

Thread overview: 33+ 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 ` [PATCH V2 1/5] virtio: use virtio_device_ready() in virtio_device_restore() Jason Wang
2022-04-06 11:44   ` Michael S. Tsirkin
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 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 11:59   ` Michael S. Tsirkin
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 12:00   ` Michael S. Tsirkin
2022-04-06 13:04     ` Cornelia Huck
2022-04-06 15:31       ` Michael S. Tsirkin
2022-04-07  6:38         ` Jason Wang
2022-04-07  7:52           ` Cornelia Huck [this message]
2022-04-07  8:04             ` Jason Wang
2022-04-08 13:03       ` Halil Pasic
2022-04-10  7:51         ` Michael S. Tsirkin
2022-04-11  8:22           ` Jason Wang
2022-04-11  8:56             ` Michael S. Tsirkin
2022-04-12  2:21               ` Jason Wang
2022-04-11 14:27             ` Cornelia Huck
2022-04-12  0:01               ` Halil Pasic
2022-04-12  2:24                 ` Jason Wang
2022-04-12  7:55                   ` Halil Pasic
2022-04-12 16:48                 ` Cornelia Huck
2022-04-13  2:53                   ` Jason Wang
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 12:04   ` Michael S. Tsirkin
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-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=87r169ba90.fsf@redhat.com \
    --to=cohuck@redhat.com \
    --cc=jasowang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).