From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59300) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e5YrI-0007Xr-N5 for qemu-devel@nongnu.org; Fri, 20 Oct 2017 11:05:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e5YrH-00080w-Oj for qemu-devel@nongnu.org; Fri, 20 Oct 2017 11:05:12 -0400 Received: from mail-oi0-x242.google.com ([2607:f8b0:4003:c06::242]:47134) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e5YrH-00080U-JD for qemu-devel@nongnu.org; Fri, 20 Oct 2017 11:05:11 -0400 Received: by mail-oi0-x242.google.com with SMTP id h200so20463368oib.4 for ; Fri, 20 Oct 2017 08:05:11 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20171020080049.GA25471@infradead.org> References: <20171012155027.3277-1-pagupta@redhat.com> <20171012155027.3277-3-pagupta@redhat.com> <20171017071633.GA9207@infradead.org> <1441791227.21027037.1508226056893.JavaMail.zimbra@redhat.com> <20171017080236.GA27649@infradead.org> <670833322.21037148.1508229041158.JavaMail.zimbra@redhat.com> <20171018130339.GB29767@stefanha-x1.localdomain> <20171019080149.GB10089@infradead.org> <20171020080049.GA25471@infradead.org> From: Dan Williams Date: Fri, 20 Oct 2017 08:05:09 -0700 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [Qemu-devel] [RFC 2/2] KVM: add virtio-pmem driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: Stefan Hajnoczi , Pankaj Gupta , Kevin Wolf , haozhong zhang , Jan Kara , xiaoguangrong eric , KVM list , David Hildenbrand , linux-nvdimm , ross zwisler , "linux-kernel@vger.kernel.org" , Qemu Developers , Linux MM , Stefan Hajnoczi , Paolo Bonzini , Nitesh Narayan Lal On Fri, Oct 20, 2017 at 1:00 AM, Christoph Hellwig wrote: > On Thu, Oct 19, 2017 at 11:21:26AM -0700, Dan Williams wrote: >> The difference is that nvdimm_flush() is not mandatory, and that the >> platform will automatically perform the same flush at power-fail. >> Applications should be able to assume that if they are using MAP_SYNC >> that no other coordination with the kernel or the hypervisor is >> necessary. >> >> Advertising this as a generic Persistent Memory range to the guest >> means that the guest could theoretically use it with device-dax where >> there is no driver or filesystem sync interface. The hypervisor will >> be waiting for flush notifications and the guest will just issue cache >> flushes and sfence instructions. So, as far as I can see we need to >> differentiate this virtio-model from standard "Persistent Memory" to >> the guest and remove the possibility of guests/applications making the >> wrong assumption. > > So add a flag that it is not. We already have the nd_volatile type, > that is special. For now only in Linux, but I think adding this type > to the spec eventually would be very useful for efficiently exposing > directly mappable device to VM guests. Right, that's the same recommendation I gave. https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg08404.html ...so maybe I'm misunderstanding your concern? It sounds like we're on the same page.