| Message ID | 20200219174354.84726-2-roger.pau@citrix.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | x86: improve assisted tlb flush and use it in guest mode | expand |
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.pau@citrix.com> > Reviewed-by: Wei Liu <wl@xen.org> With a suitable clarification added Acked-by: Jan Beulich <jbeulich@suse.com> Jan
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@citrix.com> > > Reviewed-by: Wei Liu <wl@xen.org> > > With a suitable clarification added > Acked-by: Jan Beulich <jbeulich@suse.com> Thanks, Roger.
On 28.02.2020 16:27, Roger Pau Monné wrote: > 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? Could you perhaps start with "Compilers will normally ..." I'm fine with the rest, it's just that "most compilers" still feels like an understatement. Jan
On Fri, Feb 28, 2020 at 04:47:57PM +0100, Jan Beulich wrote: > On 28.02.2020 16:27, Roger Pau Monné wrote: > > 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? > > Could you perhaps start with "Compilers will normally ..." I'm fine > with the rest, it's just that "most compilers" still feels like > an understatement. Sure, that's fine. Thanks, Roger.
diff --git a/xen/arch/x86/hvm/asid.c b/xen/arch/x86/hvm/asid.c index 8e00a28443..63ce462d56 100644 --- a/xen/arch/x86/hvm/asid.c +++ b/xen/arch/x86/hvm/asid.c @@ -83,7 +83,7 @@ void hvm_asid_init(int nasids) void hvm_asid_flush_vcpu_asid(struct hvm_vcpu_asid *asid) { - asid->generation = 0; + write_atomic(&asid->generation, 0); } void hvm_asid_flush_vcpu(struct vcpu *v) @@ -121,7 +121,7 @@ bool_t hvm_asid_handle_vmenter(struct hvm_vcpu_asid *asid) goto disabled; /* Test if VCPU has valid ASID. */ - if ( asid->generation == data->core_asid_generation ) + if ( read_atomic(&asid->generation) == data->core_asid_generation ) return 0; /* If there are no free ASIDs, need to go to a new generation */ @@ -135,7 +135,7 @@ bool_t hvm_asid_handle_vmenter(struct hvm_vcpu_asid *asid) /* Now guaranteed to be a free ASID. */ asid->asid = data->next_asid++; - asid->generation = data->core_asid_generation; + write_atomic(&asid->generation, data->core_asid_generation); /* * When we assign ASID 1, flush all TLB entries as we are starting a new