7:54 p.m.
[ add Tony, who has wrestled with how to detect rep; movs recover-ability ]
On Sun, Mar 10, 2019 at 1:02 PM Linus Torvalds
<torvalds(a)linux-foundation.org> wrote:
On Sun, Mar 10, 2019 at 12:54 PM Dan Williams <dan.j.williams(a)intel.com> wrote:
>
> Hi Linus, please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
> tags/devdax-for-5.1
>
> ...to receive new device-dax infrastructure to allow persistent memory
> and other "reserved" / performance differentiated memories, to be
> assigned to the core-mm as "System RAM".
I'm not pulling this until I get official Intel clarification on the
whole "pmem vs rep movs vs machine check" behavior.
Last I saw it was deadly and didn't work, and we have a whole "mc-safe
memory copy" thing for it in the kernel because repeat string
instructions didn't work correctly on nvmem.
No way am I exposing any users to something like that.
We need a way to know when it works and when it doesn't, and only do
it when it's safe.
Unfortunately this particular b0rkage is not constrained to nvmem.
I.e. there's nothing specific about nvmem requiring mc-safe memory
copy, it's a cpu problem consuming any poison regardless of
source-media-type with "rep; movs".