On 14/06/2019 15:36, Andrii Anisov wrote:
Hello Julien,
Hi,
On 13.06.19 17:41, Julien Grall wrote:
Sorry I may have missed it. We can't really restrict the usage of the current
hypercall (it is pretty lax). So I think any lockless solution would require
to allow the hypercall
to be used together (which I want to avoid).
I'd better say here allowing using phys and virt registered runstates together
(and independently).
And me personally for this approach, for sure not encouraging users (guests) to
do so.
Why? What are the benefits for a guest to use the two interface together? After
all they have exactly the same data...
If we agree to allow the two hypercalls to be used together, then if we
protect the update with domain_lock() then you should be able to avoid any
race with the update path as onlining a vCPU requires to take the
domain_lock() (see do_vcpu_op for x86 and do_common_cpu_on for Arm).
Could you please clarify are you saying about protection runstate mapping update
or runstate values update?
runstate mapping.
BTW, I'm a bit confused, are you OK with lock (not trylock) existing in
hypercall?
This is still in discussion.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel