On Fri, Feb 28, 2020 at 02:29:09PM +0100, Jan Beulich wrote: > 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.
What about adding: > > 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. "Most compilers will already do such writes and reads as a single instruction, so the usage of atomic operations is mostly used as a safety measure." Here? > > 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> Thanks, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
