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=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 252CBC433B4 for ; Tue, 4 May 2021 05:44:11 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 82B7661027 for ; Tue, 4 May 2021 05:44:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 82B7661027 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 5A356100EB848; Mon, 3 May 2021 22:44:10 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::136; helo=mail-il1-x136.google.com; envelope-from=pankaj.gupta.linux@gmail.com; receiver= Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 95F4A100EB83F for ; Mon, 3 May 2021 22:44:07 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id p15so5457581iln.3 for ; Mon, 03 May 2021 22:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G9ESRXefOvFcFU8JizCeiw+vMSlHN+RPYh9AjhBOqb8=; b=G5DClEfzuTVYVNRsJKfQJ2Q1QTCN37SlLVFqqvhciqDzHPQ8XnFr/N9dHmw9TTfN0E VggOshctvx5Zzn4ijwk+NXVBCytTblKaq5629URM4CAT21Wbb2K9q3OQm/ndSud7R3pE 8cgnqNtHpaIC1YNScouwr2wZWkYcGdwQZSsGoF6WGwomhGjRvhMdi/9TicMzEkGUDxc6 zJ8OI1WwyGfzkvfPkukevttNOdxFfQwLEtQXFuzGhjhm5GOeN4+Hy6JHPr6Y4VolxemC tHlCiWuXhyS3cTMq8rUTYfA5+F1p+otPe2Ke3gKn0kOznsDMJABwwOg5LUijFQ8jZu7y Lsxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G9ESRXefOvFcFU8JizCeiw+vMSlHN+RPYh9AjhBOqb8=; b=C2jenmXh/f27RnCI0vto8CH7JKpIufnwW8yCwZRLp91pNhVXFURx0zqzfBVt9KQvzb cwN0sQyzVpAj5zdTG+KBzAR1yhK+5w/hIXQ5dakKaSihExKFD4XRCfX8Rq2kwDn287n5 spkjyg8EImqMotm5NVnTOqEzHSQk0AH43+YDfYy9AGWVS4/aIexakjDfV5Wc4TYyiui+ c784hmGx5H8rfe6yJuH5FbV/d6btilFcD7Pjws5X6Ysxhos41MMhwK6htmszGZVFu0ZL 77l9QYjcKvg60bfu4qMkOXBfBBLjcN/n4IfV5tKFX0Dijvy2jdWPqICiknV6bAhHVxGK CIiw== X-Gm-Message-State: AOAM532X3xxftghRIhQF3JbzBfh6UE+S3JK7+g+Qtkzcs/Lyoid8Bwjd x5jn8JTbNgWZUfmdEwZIpnf65v9VhoZVLkz+NlA= X-Google-Smtp-Source: ABdhPJzC6alOzJqNjv57N04F4U3tHUEdbtp1zl/QgLQrapXHd+EvE5w35e9Iti1fnaIY0tTwULyBboMTw8lYepmsnxs= X-Received: by 2002:a05:6e02:160d:: with SMTP id t13mr19821606ilu.85.1620107045748; Mon, 03 May 2021 22:44:05 -0700 (PDT) MIME-Version: 1.0 References: <161966810162.652.13723419108625443430.stgit@17be908f7c1c>

In-Reply-To: From: Pankaj Gupta Date: Tue, 4 May 2021 07:43:53 +0200 Message-ID: Subject: Re: [PATCH v4 0/3] nvdimm: Enable sync-dax property for nvdimm To: "Aneesh Kumar K.V" Message-ID-Hash: G6THHVJKETCZOELJQDNQHFJBUCBLUDQ5 X-Message-ID-Hash: G6THHVJKETCZOELJQDNQHFJBUCBLUDQ5 X-MailFrom: pankaj.gupta.linux@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: Shivaprasad G Bhat , David Gibson , Greg Kurz , qemu-ppc@nongnu.org, Eduardo Habkost , Marcel Apfelbaum , "Michael S. Tsirkin" , Igor Mammedov , Xiao Guangrong , Peter Maydell , Eric Blake , qemu-arm@nongnu.org, richard.henderson@linaro.org, Paolo Bonzini , Stefan Hajnoczi , Haozhong Zhang , shameerali.kolothum.thodi@huawei.com, kwangwoo.lee@sk.com, Markus Armbruster , Qemu Developers , linux-nvdimm , kvm-ppc@vger.kernel.org, shivaprasadbhat@gmail.com, bharata@linux.vnet.ibm.com X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > The proposal that "sync-dax=unsafe" for non-PPC architectures, is a > > fundamental misrepresentation of how this is supposed to work. Rather > > than make "sync-dax" a first class citizen of the device-description > > interface I'm proposing that you make this a separate device-type. > > This also solves the problem that "sync-dax" with an implicit > > architecture backend assumption is not precise, but a new "non-nvdimm" > > device type would make it explicit what the host is advertising to the > > guest. > > > > Currently, users can use a virtualized nvdimm support in Qemu to share > host page cache to the guest via the below command > > -object memory-backend-file,id=memnvdimm1,mem-path=file_name_in_host_fs > -device nvdimm,memdev=memnvdimm1 > > Such usage can results in wrong application behavior because there is no > hint to the application/guest OS that a cpu cache flush is not > sufficient to ensure persistence. > > I understand that virio-pmem is suggested as an alternative for that. > But why not fix virtualized nvdimm if platforms can express the details. > > ie, can ACPI indicate to the guest OS that the device need a flush > mechanism to ensure persistence in the above case? > > What this patch series did was to express that property via a device > tree node and guest driver enables a hypercall based flush mechanism to > ensure persistence. Would VIRTIO (entirely asynchronous, no trap at host side) based mechanism is better than hyper-call based? Registering memory can be done any way. We implemented virtio-pmem flush mechanisms with below considerations: - Proper semantic for guest flush requests. - Efficient mechanism for performance pov. I am just asking myself if we have platform agnostic mechanism already there, maybe we can extend it to suit our needs? Maybe I am missing some points here. > >> On PPC, the default is "sync-dax=writeback" - so the ND_REGION_ASYNC > >> > >> is set for the region and the guest makes hcalls to issue fsync on the host. > >> > >> > >> Are you suggesting me to keep it "unsafe" as default for all architectures > >> > >> including PPC and a user can set it to "writeback" if desired. > > > > No, I am suggesting that "sync-dax" is insufficient to convey this > > property. This behavior warrants its own device type, not an ambiguous > > property of the memory-backend-file with implicit architecture > > assumptions attached. > > > > Why is it insufficient? Is it because other architectures don't have an > ability express this detail to guest OS? Isn't that an arch limitations? _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org