From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtualization@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, maz@kernel.org, tglx@linutronix.de,
peterz@infradead.org, sgarzare@redhat.com,
"Paul E. McKenney" <paulmck@kernel.org>
Subject: Re: [PATCH V2 3/5] virtio: introduce config op to synchronize vring callbacks
Date: Thu, 7 Apr 2022 14:25:44 +0800 [thread overview]
Message-ID: <53831b99-6c63-7ca9-9b95-bc3f8c5e015c@redhat.com> (raw)
In-Reply-To: <20220406075405-mutt-send-email-mst@kernel.org>
在 2022/4/6 下午7:59, Michael S. Tsirkin 写道:
> On Wed, Apr 06, 2022 at 04:35:36PM +0800, Jason Wang wrote:
>> This patch introduce
> introduces
>
>> a new
> new
>
>> virtio config ops to vring
>> callbacks. Transport specific method is required to call
>> synchornize_irq() on the IRQs. For the transport that doesn't provide
>> synchronize_vqs(), use synchornize_rcu() as a fallback.
>>
>> 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>
>> ---
>> include/linux/virtio_config.h | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
>> index b341dd62aa4d..08b73d9bbff2 100644
>> --- a/include/linux/virtio_config.h
>> +++ b/include/linux/virtio_config.h
>> @@ -57,6 +57,8 @@ struct virtio_shm_region {
>> * include a NULL entry for vqs unused by driver
>> * Returns 0 on success or error status
>> * @del_vqs: free virtqueues found by find_vqs().
>> + * @synchronize_vqs: synchronize with the virtqueue callbacks.
>> + * vdev: the virtio_device
> I think I prefer synchronize_callbacks
Ok, I will rename it.
>
>> * @get_features: get the array of feature bits for this device.
>> * vdev: the virtio_device
>> * Returns the first 64 feature bits (all we currently need).
>> @@ -89,6 +91,7 @@ struct virtio_config_ops {
>> const char * const names[], const bool *ctx,
>> struct irq_affinity *desc);
>> void (*del_vqs)(struct virtio_device *);
>> + void (*synchronize_vqs)(struct virtio_device *);
>> u64 (*get_features)(struct virtio_device *vdev);
>> int (*finalize_features)(struct virtio_device *vdev);
>> const char *(*bus_name)(struct virtio_device *vdev);
>> @@ -217,6 +220,19 @@ int virtio_find_vqs_ctx(struct virtio_device *vdev, unsigned nvqs,
>> desc);
>> }
>>
>> +/**
>> + * virtio_synchronize_vqs - synchronize with virtqueue callbacks
>> + * @vdev: the device
>> + */
>> +static inline
>> +void virtio_synchronize_vqs(struct virtio_device *dev)
>> +{
>> + if (dev->config->synchronize_vqs)
>> + dev->config->synchronize_vqs(dev);
>> + else
>> + synchronize_rcu();
> I am not sure about this fallback and the latency impact.
Unless each transport can implement their own synchronization routine,
we need something that can do best effort as fallback here.
> Maybe synchronize_rcu_expedited is better here.
Not sure, it might lead IPIs and according to the
Documentation/RCU/checklist.rst:
"""
The expedited forms of these primitives have the same semantics
as the non-expedited forms, but expediting is both expensive and
(with the exception of synchronize_srcu_expedited()) unfriendly
to real-time workloads. Use of the expedited primitives should
be restricted to rare configuration-change operations that would
not normally be undertaken while a real-time workload is running.
However, real-time workloads can use rcupdate.rcu_normal kernel
boot parameter to completely disable expedited grace periods,
though this might have performance implications.
"""
It will be expensive for real time workloads.
Thanks
>
>> +}
>> +
>> /**
>> * virtio_device_ready - enable vq use in probe function
>> * @vdev: the device
>> --
>> 2.25.1
next prev parent reply other threads:[~2022-04-07 6:25 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 [this message]
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
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=53831b99-6c63-7ca9-9b95-bc3f8c5e015c@redhat.com \
--to=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=mst@redhat.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: 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
all inboxes | Powered by JetHome®