Excerpts from Shawn Anastasio's message of August 18, 2020 5:14 am:
> I'm a bit concerned about the removal of PROT_SAO.
> 
>  From what I can see, a feature like this would be extremely useful for
> emulating architectures with stronger memory models. QEMU's multi-
> threaded TCG project in particular looks like it would be a good
> candidate, since as far as I'm aware it is currently completely
> unable to perform strong-on-weak emulation.
> 
> Without hardware support like SAO provides, the only way I could see
> to achieve this would be by emitting tons of unnecessary and costly
> memory barrier instructions.
> 
> I understand that ISA 3.1 and POWER10 have dropped SAO, but as a POWER9
> user it seems a bit silly to have a potentially useful feature dropped
> from the kernel just because a future processor doesn't support it.
> 
> Curious to hear more thoughts on this.

Very reasonable point.

The problem we're trying to get a handle on is live partition migration
where a running guest might be using SAO then get migrated to a P10. I
don't think we have a good way to handle this case. Potentially the
hypervisor could revoke the page tables if the guest is running in hash
mode and the guest kernel could be taught about that and sigbus the
process, but in radix the guest controls those page tables and the SAO
state and I don't think there's a way to cause it to take a fault.

I also don't know what the proprietary hypervisor does here.

We could add it back, default to n, or make it bare metal only, or
somehow try to block live migration to a later CPU without the faciliy.
I wouldn't be against that.

It would be very interesting to know how it performs in such a "real"
situation. I don't know how well POWER9 has optimised it -- it's
possible that it's not much better than putting lwsync after every load
or store.

Thanks,
Nick

Reply via email to