Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion

From: Pankaj Gupta <pagupta@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Jan Kara <jack@suse.cz>,
	Xiao Guangrong <xiaoguangrong.eric@gmail.com>,
	kvm-devel <kvm@vger.kernel.org>, Amit Shah <amit@kernel.org>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	Ross Zwisler <ross.zwisler@intel.com>,
	Qemu Developers <qemu-devel@nongnu.org>,
	Christoph Hellwig <hch@infradead.org>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Nitesh Narayan Lal <nilal@redhat.com>,
	Aams@amazon.com
Subject: Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion
Date: Tue, 7 Nov 2017 06:21:36 -0500 (EST)	[thread overview]
Message-ID: <1412426579.28360924.1510053696238.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <CAPcyv4jdJwUQTy7O7Ar82J+gAi54ycCTa=HSfXY5Ogwqi+oC-Q@mail.gmail.com>

> >
> >
> >> [..]
> >> >> Yes, the GUID will specifically identify this range as "Virtio Shared
> >> >> Memory" (or whatever name survives after a bikeshed debate). The
> >> >> libnvdimm core then needs to grow a new region type that mostly
> >> >> behaves the same as a "pmem" region, but drivers/nvdimm/pmem.c grows a
> >> >> new flush interface to perform the host communication. Device-dax
> >> >> would be disallowed from attaching to this region type, or we could
> >> >> grow a new device-dax type that does not allow the raw device to be
> >> >> mapped, but allows a filesystem mounted on top to manage the flush
> >> >> interface.
> >> >
> >> >
> >> > I am afraid it is not a good idea that a single SPA is used for multiple
> >> > purposes. For the region used as "pmem" is directly mapped to the VM so
> >> > that guest can freely access it without host's assistance, however, for
> >> > the region used as "host communication" is not mapped to VM, so that
> >> > it causes VM-exit and host gets the chance to do specific operations,
> >> > e.g, flush cache. So we'd better distinctly define these two regions to
> >> > avoid the unnecessary complexity in hypervisor.
> >>
> >> Good point, I was assuming that the mmio flush interface would be
> >> discovered separately from the NFIT-defined memory range. Perhaps via
> >> PCI in the guest? This piece of the proposal  needs a bit more
> >> thought...
> >
> > Also, in earlier discussions we agreed for entire device flush whenever
> > guest
> > performs a fsync on DAX file. If we do a MMIO call for this, guest CPU
> > would be
> > trapped for the duration device flush is completed.
> >
> > Instead, if we do perform an asynchronous flush guest CPU's can be utilized
> > by
> > some other tasks till flush completes?
> 
> Yes, the interface for the guest to trigger and wait for flush
> requests should be asynchronous, just like a storage "flush-cache"
> command.

One idea got while discussing this with Rik & Amit during KVM forum is to use something 
similar to Hyperv Key-value pair for sharing command between guest <=> host. Don't think 
such thing exists yet for KVM? Or how we can utilize existing features in KVM to achieve this?
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm