On 4/6/21 5:07 PM, Vaibhav Jain wrote:
Hi Aneesh,
Thanks for looking into this patch.
"Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxx> writes:
Vaibhav Jain <vaibhav@xxxxxxxxxxxxx> writes:
In case a platform doesn't provide explicit flush-hints but provides an
explicit flush callback via ND_REGION_ASYNC region flag, then
nvdimm_has_flush() still returns '0' indicating that writes do not
require flushing. This happens on PPC64 with patch at [1] applied,
where 'deep_flush' of a region was denied even though an explicit
flush function was provided.
Similar problem is also seen with virtio-pmem where the 'deep_flush'
sysfs attribute is not visible as in absence of any registered nvdimm,
'nd_region->ndr_mappings == 0'.
Fix this by updating nvdimm_has_flush() adding a condition to
nvdimm_has_flush() testing for ND_REGION_ASYNC flag on the region
and see if a 'region->flush' callback is assigned. Also remove
explicit test for 'nd_region->ndr_mapping' since regions can be marked
'ND_REGION_SYNC' without any explicit mappings as in case of
virtio-pmem.
Do we need to check for ND_REGION_ASYNC? What if the backend wants to
provide a synchronous dax region but with different deep flush semantic
than writing to wpq flush address?
ie,
For a synchronous dax region, writes arent expected to require any
flushing (or deep-flush) so this function should ideally return '0' in
such a case. Hence I had added the test for ND_REGION_ASYNC region flag.
that is not correct. For example, we could ideally move the wpq flush as
an nd_region->flush callback for acpi or we could implement a deep flush
for a synchronous dax region exposed by papr_scm driver that ensures
stores indeed reached the media managed by the hypervisor.
-aneesh
