On 19.02.2020 18:43, Roger Pau Monne wrote: > Current implementation of hvm_asid_flush_vcpu is not safe to use > unless the target vCPU is either paused or the currently running one, > as it modifies the generation without any locking.
Indeed, but the issue you're taking care of is highly theoretical: I don't think any sane compiler will split writes of the fields to multiple insns. It would be nice if this was made clear here. > Fix this by using atomic operations when accessing the generation > field, both in hvm_asid_flush_vcpu_asid and other ASID functions. This > allows to safely flush the current ASID generation. Note that for the > flush to take effect if the vCPU is currently running a vmexit is > required. > > Note the same could be achieved by introducing an extra field to > hvm_vcpu_asid that signals hvm_asid_handle_vmenter the need to call > hvm_asid_flush_vcpu on the given vCPU before vmentry, this however > seems unnecessary as hvm_asid_flush_vcpu itself only sets two vCPU > fields to 0, so there's no need to delay this to the vmentry ASID > helper. > > This is not a bugfix as no callers that would violate the assumptions > listed in the first paragraph have been found, but a preparatory > change in order to allow remote flushing of HVM vCPUs. > > Signed-off-by: Roger Pau Monné <roger....@citrix.com> > Reviewed-by: Wei Liu <w...@xen.org> With a suitable clarification added Acked-by: Jan Beulich <jbeul...@suse.com> Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
