[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3] xen: introduce VCPUOP_register_runstate_phys_memory_area hypercall
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@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |