Re: [Xen-devel] [PATCH v5 1/7] x86/hvm: allow ASID flush when v != current

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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.pau@xxxxxxxxxx>
> > Reviewed-by: Wei Liu <wl@xxxxxxx>
> 
> With a suitable clarification added
> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel