From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F986C43387 for ; Wed, 9 Jan 2019 18:08:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D40B1214C6 for ; Wed, 9 Jan 2019 18:08:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727464AbfAISI1 (ORCPT ); Wed, 9 Jan 2019 13:08:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51970 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725775AbfAISI0 (ORCPT ); Wed, 9 Jan 2019 13:08:26 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BF1A37F3EA; Wed, 9 Jan 2019 18:08:25 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4B3085D75D; Wed, 9 Jan 2019 18:08:25 +0000 (UTC) Received: from zmail21.collab.prod.int.phx2.redhat.com (zmail21.collab.prod.int.phx2.redhat.com [10.5.83.24]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 7CF9A3F954; Wed, 9 Jan 2019 18:08:24 +0000 (UTC) Date: Wed, 9 Jan 2019 13:08:24 -0500 (EST) From: Pankaj Gupta To: "Darrick J. Wong" Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, qemu-devel@nongnu.org, linux-nvdimm@ml01.01.org, linux-fsdevel@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-acpi@vger.kernel.org, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, jack@suse.cz, stefanha@redhat.com, dan j williams , riel@surriel.com, nilal@redhat.com, kwolf@redhat.com, pbonzini@redhat.com, zwisler@kernel.org, vishal l verma , dave jiang , david@redhat.com, jmoyer@redhat.com, xiaoguangrong eric , hch@infradead.org, mst@redhat.com, jasowang@redhat.com, lcapitulino@redhat.com, imammedo@redhat.com, eblake@redhat.com, willy@infradead.org, tytso@mit.edu, adilger kernel , rjw@rjwysocki.net Message-ID: <739751810.61274195.1547057304156.JavaMail.zimbra@redhat.com> In-Reply-To: <20190109162654.GW12689@magnolia> References: <20190109144736.17452-1-pagupta@redhat.com> <20190109144736.17452-6-pagupta@redhat.com> <20190109162654.GW12689@magnolia> Subject: Re: [PATCH v3 5/5] xfs: disable map_sync for virtio pmem MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.116.35, 10.4.195.20] Thread-Topic: disable map_sync for virtio pmem Thread-Index: /ZsbeUyQdaKN0/+N725z2SUxPGgcrQ== X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 09 Jan 2019 18:08:26 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > Virtio pmem provides asynchronous host page cache flush > > mechanism. we don't support 'MAP_SYNC' with virtio pmem > > and xfs. > > > > Signed-off-by: Pankaj Gupta > > --- > > fs/xfs/xfs_file.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c > > index e474250..eae4aa4 100644 > > --- a/fs/xfs/xfs_file.c > > +++ b/fs/xfs/xfs_file.c > > @@ -1190,6 +1190,14 @@ xfs_file_mmap( > > if (!IS_DAX(file_inode(filp)) && (vma->vm_flags & VM_SYNC)) > > return -EOPNOTSUPP; > > > > + /* We don't support synchronous mappings with guest direct access > > + * and virtio based host page cache mechanism. > > + */ > > + if (IS_DAX(file_inode(filp)) && virtio_pmem_host_cache_enabled( > > Echoing what Jan said, this ought to be some sort of generic function > that tells us whether or not memory mapped from the dax device will > always still be accessible even after a crash (i.e. supports MAP_SYNC). o.k > > What if the underlying file on the host is itself on pmem and can be > MAP_SYNC'd? Shouldn't the guest be able to use MAP_SYNC as well? Guest MAP_SYNC on actual host pmem will sync guest metadata, as guest writes are persistent on actual pmem. Host side Qemu MAP_SYNC enabling work for pmem is in progress. It will make sure metadata at host side is in consistent state after a crash or any other metadata corruption operation. For virtio-pmem, we are emulating pmem device over regular storage on host side. Guest need to call fsync followed by write to make sure guest metadata is in consistent state(or journalled). Host backing file data & metadata will also be persistent after guest to host fsync. Thanks, Pankaj