sparc64: DAX memory needs persistent mappings

sparc64: DAX memory needs persistent mappings

Orabug: 25888596

Memory allocated on behalf of dax_alloc() is mapped by two
distinct MMU translations, one set for userland, which is backed by
regular 8k virtual pages, and another set for feeding to the
hypervisor, and these are kernel virtual addresses backed
by 4Mb pages. These latter translations are only used when
the memory is allocated/deallocated and when a dax transaction
is submitted. So the translations are unlikely to be in the TLB,
and eventually may be evicted from the kernel TSB after some time.
This leads to ENOMAP errors reported by the hypervisor. In order
to avoid this, we "touch" such pages just before dax_submit
which will fault translations into the tlb/tsb if necessary.

A future performance optimization is to take advantage of the "real
address has pagesize" feature which is available in very recent
versions of hypervisor f/w. In this case we can convert the address
in the ccb to a real address with the correct bits to specify
a 4Mb pagesize, and change the address type to real. Then the
memory touch would be unnecessary and the HV would not need to
probe the tlb/tsb at all.

Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Reviewed-by: HÃ¥kon Bugge <haakon.bugge@oracle.com>
Reviewed-by: Jonathan Helman <jonathan.helman@oracle.com>
Signed-off-by: Allen Pais <allen.pais@oracle.com>