Hi Jan,
As discussed in [1], I think it would good to revive this patch.
AFAICT, this patch was dropped because the performance was thought to be
minimal. However, I think it would be a better way to resolve the
problem that one is trying to address [1].
So I will do another review of this patch.
On 27/01/2021 08:16, Jan Beulich wrote:
Especially for the use in evtchn_move_pirqs() (called when moving a vCPU
across pCPU-s) and the ones in EOI handling in PCI pass-through code,
serializing perhaps an entire domain isn't helpful when no state (which
isn't e.g. further protected by the per-channel lock) changes.
Unfortunately this implies dropping of lock profiling for this lock,
until r/w locks may get enabled for such functionality.
While ->notify_vcpu_id is now meant to be consistently updated with the
per-channel lock held, an extension applies to ECS_PIRQ: The field is
also guaranteed to not change with the per-domain event lock held for
writing. Therefore the link_pirq_port() call from evtchn_bind_pirq()
could in principle be moved out of the per-channel locked regions, but
this further code churn didn't seem worth it.
This doesn't seem to apply on upstream anymore. Would you be able to
respin it?
I have looked at the place where you use read_lock() rather than
write_lock(). They all look fine to me, so I would be fine to give my
reviewed-by on the next version (assuming there are nothing wrong with
the rebase :)).
Cheers,
[1]
https://lore.kernel.org/xen-devel/acd0dfae-b045-8505-3f6c-30ce72653...@suse.com/
--
Julien Grall
