Jan, Julien,
On 11.06.19 12:10, Jan Beulich wrote:
At the very least such loops want a cpu_relax() in their bodies.
But this being on a hypercall path - are there theoretical guarantees
that a guest can't abuse this to lock up a CPU?
Hmmm, I suggested this but it looks like a guest may call the hypercall multiple
time from different vCPU. So this could be a way to delay work on the CPU.
I wanted to make the context switch mostly lockless and therefore avoiding to
introduce a spinlock.
Well, constructs like the above are trying to mimic a spinlock
without actually using a spinlock. There are extremely rare
situation in which this may indeed be warranted, but here it
falls in the common "makes things worse overall" bucket, I
think. To not unduly penalize the actual update paths, I think
using a r/w lock would be appropriate here.
So what is the conclusion here? Should we go with trylock and
hypercall_create_continuation() in order to avoid locking but still not fail to
the guest?
--
Sincerely,
Andrii Anisov.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
