On Thu, Jun 20, 2019 at 2:31 PM Andi Kleen <andi@xxxxxxxxxxxxxx> wrote: > > Dan Williams <dan.j.williams@xxxxxxxxx> writes: > > > > The underlying issue is that the x86-PAT implementation wants to > > ensure that conflicting mappings are not set up for the same physical > > address. This is mentioned in the developer manuals as problematic on > > some cpus. Andi, is lookup_memtype() and track_pfn_insert() still > > relevant? > > There have been discussions about it in the past, and the right answer > will likely differ for different CPUs: But so far the official answer > for Intel CPUs is that these caching conflicts should be avoided. > Ok. > So I guess the cache in the original email makes sense for now. I wouldn't go that far, but it does mean that if we go ahead with caching the value as a dax_device property there should at least be a debug option to assert that the device value conforms to all the other mappings. Another failing of the track_pfn_insert() and lookup_memtype() implementation is that it makes it awkward to handle marking mappings UC to prevent speculative consumption of poison. That is something that is better handled, in my opinion, by asking the device for the pgprot and coordinating shooting down any WB mappings of the same physical page.
