From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e5SF7-0007v3-Nd for qemu-devel@nongnu.org; Fri, 20 Oct 2017 04:01:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e5SF4-0002Nc-0d for qemu-devel@nongnu.org; Fri, 20 Oct 2017 04:01:21 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:55901) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e5SF3-0002CD-RP for qemu-devel@nongnu.org; Fri, 20 Oct 2017 04:01:17 -0400 Date: Fri, 20 Oct 2017 01:00:49 -0700 From: Christoph Hellwig Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Dan Williams Cc: Christoph Hellwig , 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 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.