"Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxx> writes: > 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. Sure, makes sense now. I have sent out a v3 of this patch with this addressed. > > -aneesh -- Cheers ~ Vaibhav
