On 2020/8/5 下午1:49, Zhu, Lingshan wrote:
On 8/5/2020 10:16 AM, Jason Wang wrote:
On 2020/8/4 下午5:21, Michael S. Tsirkin wrote:
+struct vhost_vring_call {
+ struct eventfd_ctx *ctx;
+ struct irq_bypass_producer producer;
+ spinlock_t ctx_lock;
It's not clear to me why we need ctx_lock here.
Thanks
Hi Jason,
we use this lock to protect the eventfd_ctx and irq from race
conditions,
We don't support irq notification from vDPA device driver in this
version,
do we still have race condition?
Thanks
Jason I'm not sure what you are trying to say here.
I meant we change the API from V4 so driver won't notify us if irq is
changed.
Then it looks to me there's no need for the ctx_lock, everyhing could
be synchronized with vq mutex.
Thanks
from V4 to V5, there are only some minor improvements and bug fix, get_vq_irq() almost stays untouched, mutex can work for this, however I see the vq mutex is used in many scenarios.
We only use this lock to protect the producer information, can this help to get less coupling, defensive code for less bugs?
I think not, vq mutex is used to protect all vq related data structure,
introducing another one will increase the complexity.
Thanks
Thanks
