Page MenuHomeFreeBSD

vmm: fix vcpu atomic load
ClosedPublic

Authored by br on Mon, Oct 28, 1:15 PM.
Tags
None
Referenced Files
F102039298: D47306.diff
Wed, Nov 6, 8:37 PM
F101980477: D47306.diff
Wed, Nov 6, 3:07 AM
F101963206: D47306.id.diff
Tue, Nov 5, 8:59 PM
Unknown Object (File)
Tue, Nov 5, 3:40 AM
Unknown Object (File)
Fri, Nov 1, 4:41 PM
Unknown Object (File)
Tue, Oct 29, 6:39 PM
Unknown Object (File)
Tue, Oct 29, 5:04 PM

Details

Summary

Load vcpu with acquire semantics as we are making a critical section between creating vcpu and using it.

Test Plan

tested on risc-v only

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

br requested review of this revision.Mon, Oct 28, 1:15 PM

In particular, this is paired with an atomic_store_rel_ptr a few lines below. I think in practice this is probably a no-op as any dependent memory accesses are reads of data that vcpu points to, and if you had a mispredicted read it would never dereference a "wrong" pointer, it would just see a NULL pointer and stop once speculation ran into a fault. That said, I do think this is more correct.

This revision is now accepted and ready to land.Mon, Oct 28, 1:29 PM
In D47306#1078749, @jhb wrote:

In particular, this is paired with an atomic_store_rel_ptr a few lines below. I think in practice this is probably a no-op as any dependent memory accesses are reads of data that vcpu points to, and if you had a mispredicted read it would never dereference a "wrong" pointer, it would just see a NULL pointer and stop once speculation ran into a fault. That said, I do think this is more correct.

This is perhaps a use-case for atomic_load_consume_ptr()? I think I agree that an acq fence is not formally required, but it looks wrong at first glance.

As an aside, we have #define atomic_load_ptr(p) (*(volatile __typeof(*p) *)(p)) - I wonder why atomic_load_acq_ptr isn't similarly defined.

This revision was automatically updated to reflect the committed changes.