x86: immediate_exit in KVM_RUN should probably be AtomicU8

[phip1611]

In cloud-hypervisor/cloud-hypervisor#7428 (comment) we are having an intense discussion about KVMs immediate_exit:

kvm/kvm-ioctls/src/ioctls/vcpu.rs

Line 1682 in 48d93d6

kvm_run.immediate_exit = val;

• The immediate_exit field should be AtomicU8
• We somehow need to expose this nicely to higher-level APIs, possibly give higher-level APIs control over the memory ordering (but I'm not too sure on the latter)

It is unfortunate that bindgen can't really automate this and it needs manual adjustment. From looking at the KVM specification and code we know that this field is supposed to be used atomically.

[rbradford]

Looking through bindgen documentation that's not doable - but we should be able to do the right thing in the kvm-ioctls wrapper method with a combination of std::mem::offset_of, AtomicU8::from_ptr(ptr) and then .store() on the atomic.

[roypat]

Does KVM access this variable atomically? We had the same discussion in firecracker a bit ago, and IIRC KVM doesn't

[phip1611]

Does KVM access this variable atomically? We had the same discussion in firecracker a bit ago, and IIRC KVM doesn't

Please look at the last sentence of my initial post :)

[roypat]

Does KVM access this variable atomically? We had the same discussion in firecracker a bit ago, and IIRC KVM doesn't

Please look at the last sentence of my initial post :)

I thought READ_ONCE was about making sure the compiler doesn't muck about with the memory access, but is unrelated to acquire/release semantics of atomic variables

[phip1611]

I'm also not 100% sure, but:

Yeah, READ_ONCE/WRITE_ONCE is generally used in the kernel under assumptions that it's basically equivalent to (or stronger than) relaxed atomics, even though by spec the implementation via volatile isn't the same

Source