Re: KVM "fake DAX" flushing interface - discussion

[Rik van Riel <riel@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]

On Tue, 2017-11-21 at 10:26 -0800, Dan Williams wrote:
> On Tue, Nov 21, 2017 at 10:19 AM, Rik van Riel <riel@redhat.com>
> wrote:
> > On Fri, 2017-11-03 at 14:21 +0800, Xiao Guangrong wrote:
> > > On 11/03/2017 12:30 AM, Dan Williams wrote:
> > > > 
> > > > 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...
> > > > 
> > > 
> > > Consider the case that the vNVDIMM device on normal storage and
> > > vNVDIMM device on real nvdimm hardware can both exist in VM, the
> > > flush interface should be able to associate with the SPA region
> > > respectively. That's why I'd like to integrate the flush
> > > interface
> > > into NFIT/ACPI by using a separate table. Is it possible to be a
> > > part of ACPI specification? :)
> > 
> > It would also be perfectly fine to have the
> > virtio PCI device indicate which vNVDIMM
> > range it flushes.
> > 
> > Since the guest OS needs to support that kind
> > of device anyway, does it really matter which
> > direction the device association points?
> > 
> > We can go with the "best" interface for what
> > could be a relatively slow flush (fsync on a
> > file on ssd/disk on the host), which requires
> > that the flushing task wait on completion
> > asynchronously.
> > 
> > If that kind of interface cannot be advertised
> > through NFIT/ACPI, wouldn't it be perfectly fine
> > to have only the virtio PCI device indicate which
> > vNVDIMM range it flushes?
> > 
> 
> Yes, we could do this with a custom PCI device, however the NFIT is
> frustratingly close to being able to define something like this. At
> the very least we can start with a "SPA Range GUID" that is Linux
> specific to indicate "call this virtio flush interface on FUA / flush
> cache requests" as a stop gap until a standardized flush interface
> can
> be defined.

Ahh, is that a "look for a device with this GUID"
NFIT hint?

That would be enough to tip off OSes that do not
support that device that they found a vNVDIMM
device that they cannot safely flush, which could
help them report such errors to userspace...

-- 
All rights reversed

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]