Dan Williams <[email protected]> writes: > On Wed, Apr 11, 2018 at 9:06 AM, Jeff Moyer <[email protected]> wrote: >> Christoph Hellwig <[email protected]> writes: >> >>> On Fri, Apr 06, 2018 at 03:41:39PM -0700, Dan Williams wrote: >>>> Yes, but the trust interface definition is what is missing, especially >>>> when we consider memmap=ss!nn and qemu-kvm. For example do we turn off >>>> DAX and/or MAP_SYNC on all platforms that don't provide a positive "I >>>> have ADR" indication (ACPI 6.2 Section 5.2.25.9 NFIT Platform >>>> Capabilities Structure)? >>> >>> Sounds like a default. >> >> Which do you turn off? DAX or MAP_SYNC (or both)? > > Only MAP_SYNC I would say, because then userspace can't opt out of > fsync/msync and it gives us a chance to "Do The Right Thing (TM)" with > respect to WPQ flush.
That works for me. >> Systems that support ACPI versions earlier than 6.2 could provide >> flush hint addresses. In that case, we could assume no ADR, and turn >> off MAP_SYNC, but still allow DAX. Note that I'm not aware of any >> hardware that actually falls into this category. >> >> Platforms prior to 6.2 that don't support flush hints are currently >> assumed to implement ADR. This proposal would change that default. >> >>>> Require opt-in when the user has trust in the hardware config that >>>> the kernel can't verify? >>> >>> And that sounds like a good config nob ontop of that default. >> >> Well, we could also make a white-list for known good platforms. I >> assume HPE's systems would be on that list. Otherwise we'd have to cook >> up udev rules, I guess? > > udev rules sound good. We can distribute them in the ndctl package. I > think I would handle this by making > /sys/bus/nd/devices/regionX/persistence_domain writable to opt-in to a > user specified persistence_domain. If the persistence_domain attribute > file is not writable then you know you're on a kernel that blindly > trusts all pmem descriptions as MAP_SYNC capable. > >> Dan, is this something you're working on now? > > No, it's behind finalizing dax-dma-vs-truncate and memcpy_mcsafe for > user copies in my queue... OK, I'll take a stab at it. Thanks, Jeff _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
