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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 432D0C433ED for ; Wed, 5 May 2021 00:12:23 +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 99280613C1 for ; Wed, 5 May 2021 00:12:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 99280613C1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.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 64F96100EB83E; Tue, 4 May 2021 17:12:22 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::636; helo=mail-ej1-x636.google.com; envelope-from=dan.j.williams@intel.com; receiver= Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 BEF3E100ED4A0 for ; Tue, 4 May 2021 17:12:19 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id y7so114896ejj.9 for ; Tue, 04 May 2021 17:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mrhPGvHlIr/7Xl07KopUpg5Wy5+M8jpP25va8IasNzg=; b=ys+mX2vjpVaHSm7uh4IF90K03qF8UO6+a+0ebX5KU1ZijOGMP4kfzLs1RFCxZyrgsP PnvWNqYQApCNMTQy31WzhCPH7jUamZ/bGcwJrJUnfMQY3wLMt/+S6T88WJDDOHfWfpo6 EVfI3XUkaiUSsMd4pJ9dS5/ddHvJFAfAXnJpaB7W9UppuibzBN862gncviGxGSw32K6l PTCdTreJnYdWHAJIB4HVUchsIz4d2D72WXAMySFB4+I8cOve8BVey0bLrVThPx7LIoaK 5mWvy3Dzl+FSUCPmf+vHyOiSicq+flEw6O+TRYIsfOJQYwIkdLQJlLIWsndp5KRNzg/P WBRQ== 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=mrhPGvHlIr/7Xl07KopUpg5Wy5+M8jpP25va8IasNzg=; b=gzx5bU8OYaD8t1jkKEzgj33q12i67bSxk/hMQJ/2WJy+vl1DqI50q/zDS12PmlKih+ lBYb7kg09M5lECxt19o0kpURZuVZEcyNf10Qg7fI//wifOyQ60++hfjuUjX9Ro/KdcKI wd460Qzhy3RNtTjwWZ8ImMRS1TkxD9uJm/0ciXzkpBHkH223RK00lAcCxzyg2lBk/3Ey /TgMewtn4lrPnioDCQn6wxRcsP5O3swqAjVaEgVp811cxSYuuyoOfSVyEvx4slY53SUM zVx/VUGfQ65MJTRPkkkH7IKqUDH4OZ0+pt+7T7ex7IP8NsWJt9KK473gVU9TIU56htM/ /bPA== X-Gm-Message-State: AOAM532vd0PaJ6eY5jBjoz/hwplv1CNCGaG4FKWL8HHctEFVw/50YUku 5Ee/034vBBNvF3DwGgItuPwNhZK5fH2sqZlPP0zD6g== X-Google-Smtp-Source: ABdhPJzbcZp8fgji7EBWOpiIEfEVjWfOuXNO53F1TLCgNI9zX3VJkgmXm7g3xjmN0SZVleyyejvSiS6aZECF7977N9M= X-Received: by 2002:a17:906:a20b:: with SMTP id r11mr24797391ejy.323.1620173537351; Tue, 04 May 2021 17:12:17 -0700 (PDT) MIME-Version: 1.0 References: <161966810162.652.13723419108625443430.stgit@17be908f7c1c>

<023e584a-6110-4d17-7fec-ca715226f869@linux.ibm.com> In-Reply-To: <023e584a-6110-4d17-7fec-ca715226f869@linux.ibm.com> From: Dan Williams Date: Tue, 4 May 2021 17:12:19 -0700 Message-ID: Subject: Re: [PATCH v4 0/3] nvdimm: Enable sync-dax property for nvdimm To: "Aneesh Kumar K.V" Message-ID-Hash: ZDUMXRL44NRKFICT4D7VOVWZRDK2JRTU X-Message-ID-Hash: ZDUMXRL44NRKFICT4D7VOVWZRDK2JRTU X-MailFrom: dan.j.williams@intel.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: Pankaj Gupta , 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 On Tue, May 4, 2021 at 2:03 AM Aneesh Kumar K.V wrote: > > On 5/4/21 11:13 AM, Pankaj Gupta wrote: > .... > > >> > >> 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. > > > > sure, virio-pmem can be used as an alternative. > > > 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. > > > > What is being attempted in this series is to indicate to the guest OS > that the backing device/file used for emulated nvdimm device cannot > guarantee the persistence via cpu cache flush instructions. Right, the detail I am arguing is that it should be a device description, not a backend file property. In other words this proposal is advocating this: -object memory-backend-file,id=mem1,share,sync-dax=$sync-dax,mem-path=$path -device nvdimm,memdev=mem1 ...and I am advocating for reusing or duplicating the virtio-pmem model like this: -object memory-backend-file,id=mem1,share,mem-path=$path -device spapr-hcall,memdev=mem1 ...because the interface to the guest is the device, not the memory-backend-file. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org 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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 0C544C433ED for ; Wed, 5 May 2021 00:14:00 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 B3158613C5 for ; Wed, 5 May 2021 00:13:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B3158613C5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:40650 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1le5As-0002U6-PQ for qemu-devel@archiver.kernel.org; Tue, 04 May 2021 20:13:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40812) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1le59O-0001DJ-3X for qemu-devel@nongnu.org; Tue, 04 May 2021 20:12:26 -0400 Received: from mail-ej1-x62a.google.com ([2a00:1450:4864:20::62a]:42753) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1le59J-0003Ji-8m for qemu-devel@nongnu.org; Tue, 04 May 2021 20:12:24 -0400 Received: by mail-ej1-x62a.google.com with SMTP id y7so114901ejj.9 for ; Tue, 04 May 2021 17:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mrhPGvHlIr/7Xl07KopUpg5Wy5+M8jpP25va8IasNzg=; b=ys+mX2vjpVaHSm7uh4IF90K03qF8UO6+a+0ebX5KU1ZijOGMP4kfzLs1RFCxZyrgsP PnvWNqYQApCNMTQy31WzhCPH7jUamZ/bGcwJrJUnfMQY3wLMt/+S6T88WJDDOHfWfpo6 EVfI3XUkaiUSsMd4pJ9dS5/ddHvJFAfAXnJpaB7W9UppuibzBN862gncviGxGSw32K6l PTCdTreJnYdWHAJIB4HVUchsIz4d2D72WXAMySFB4+I8cOve8BVey0bLrVThPx7LIoaK 5mWvy3Dzl+FSUCPmf+vHyOiSicq+flEw6O+TRYIsfOJQYwIkdLQJlLIWsndp5KRNzg/P WBRQ== 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=mrhPGvHlIr/7Xl07KopUpg5Wy5+M8jpP25va8IasNzg=; b=QoMFlHFdLF1nhwcxGKYDwJlOyn/9hXUncxK5EZlQdQHd0csjsCidy4ikc3YlKHIj63 GfeswD1OJ1KyXbWQVK9YZPVa5pjIQ3hBNpXIagsh5fxtZalJj/qBX42eb+47W0dcT8Xq lQyMaNLQAZu9gNqHR5lbEQy1ReCHwsP/k8Az5gHMiww7qlbFultGkzP+uymNAeUDwaol yxzDzgQuJGA7XUd5hpNBKLjij1mgNP7DNaSNBVcEJGZugin0l7SPg++5z6sexYXkZp1m njVrPhVsOtEaOkR7HnPlGMloAFjHYJhWzuvyX3Cs2Nq7k22rgwcJlPcfSklW8HGpQWFg RUtQ== X-Gm-Message-State: AOAM532EYymtc6PChsDJY57cksrTx9tx8zWpClnyWLGjBpF5sgjsnXS2 SrpEskNCauI8fKxLktDjNoCFBHndiKJeZw/+z72dLw== X-Google-Smtp-Source: ABdhPJzbcZp8fgji7EBWOpiIEfEVjWfOuXNO53F1TLCgNI9zX3VJkgmXm7g3xjmN0SZVleyyejvSiS6aZECF7977N9M= X-Received: by 2002:a17:906:a20b:: with SMTP id r11mr24797391ejy.323.1620173537351; Tue, 04 May 2021 17:12:17 -0700 (PDT) MIME-Version: 1.0 References: <161966810162.652.13723419108625443430.stgit@17be908f7c1c>

<023e584a-6110-4d17-7fec-ca715226f869@linux.ibm.com> In-Reply-To: <023e584a-6110-4d17-7fec-ca715226f869@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "Aneesh Kumar K.V" Cc: Pankaj Gupta , 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 On Tue, May 4, 2021 at 2:03 AM Aneesh Kumar K.V wrote: > > On 5/4/21 11:13 AM, Pankaj Gupta wrote: > .... > > >> > >> 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. > > > > sure, virio-pmem can be used as an alternative. > > > 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. > > > > What is being attempted in this series is to indicate to the guest OS > that the backing device/file used for emulated nvdimm device cannot > guarantee the persistence via cpu cache flush instructions. Right, the detail I am arguing is that it should be a device description, not a backend file property. In other words this proposal is advocating this: -object memory-backend-file,id=mem1,share,sync-dax=$sync-dax,mem-path=$path -device nvdimm,memdev=mem1 ...and I am advocating for reusing or duplicating the virtio-pmem model like this: -object memory-backend-file,id=mem1,share,mem-path=$path -device spapr-hcall,memdev=mem1 ...because the interface to the guest is the device, not the memory-backend-file.