On 7/14/20 12:29 PM, Peter Zijlstra wrote:
> On Tue, Jul 14, 2020 at 12:06:16PM -0700, Ira Weiny wrote:
>> On Tue, Jul 14, 2020 at 10:44:51AM +0200, Peter Zijlstra wrote:
>>> So, if I followed along correctly, you're proposing to do a WRMSR per
>>> k{,un}map{_atomic}(), sounds like excellent performance all-round :-(
>> Only to pages which have this additional protection, ie not DRAM.
>>
>> User mappings of this memory is not affected (would be covered by User PKeys if
>> desired). User mappings to persistent memory are the primary use case and the
>> performant path.
> Because performance to non-volatile memory doesn't matter? I think Dave
> has a better answer here ...
So, these WRMSRs are less evil than normal. They're architecturally
non-serializing instructions, just like the others in the SDM WRMSR
documentation:
Note that WRMSR to the IA32_TSC_DEADLINE MSR (MSR index 6E0H)
and the X2APIC MSRs (MSR indices 802H to 83FH) are not
serializing.
This section of the SDM needs to be updated for the PKRS. Also note
that the PKRS WRMSR is similar in its ordering properties to WRPKRU:
WRPKRU will never execute speculatively. Memory accesses
affected by PKRU register will not execute (even speculatively)
until all prior executions of WRPKRU have completed execution
and updated the PKRU register.
Which means we don't have to do silliness like LFENCE before WRMSR to
get ordering *back*. This is another tidbit that needs to get added to
the SDM. It should probably also get captured in the changelog.
But, either way, this *will* make accessing PMEM more expensive from the
kernel. No escaping that. But, we've also got customers saying they
won't deploy PMEM until we mitigate this stray write issue. Those folks
are quite willing to pay the increased in-kernel cost for increased
protection from stray kernel writes. Intel is also quite motivated
because we really like increasing the number of PMEM deployments. :)
Ira, can you make sure this all gets pulled into the changelogs somewhere?
