Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 13 Dec 2018 15:40:52 -0500
From:   Vivek Goyal <vgoyal@redhat.com>
To:     Dan Williams <dan.j.williams@intel.com>
Cc:     "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        KVM list <kvm@vger.kernel.org>,
        Miklos Szeredi <miklos@szeredi.hu>,
        Stefan Hajnoczi <stefanha@redhat.com>, sweil@redhat.com,
        Steven Whitehouse <swhiteho@redhat.com>
Subject: Re: [PATCH 15/52] fuse: map virtio_fs DAX window BAR
Message-ID: <20181213204052.GE4384@redhat.com>
References: <20181210171318.16998-1-vgoyal@redhat.com>
 <20181210171318.16998-16-vgoyal@redhat.com>
 <CAA9_cmdLvFqG_Us5ZoBopj2ssWzxVbyNqf4XcgmY+=D_gARWDA@mail.gmail.com>
 <20181213200936.GU2313@work-vm>
 <CAPcyv4hwPBGLkAN8MKhtti8e-=hksg+oD3CDAUY6B9uh54zBLw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPcyv4hwPBGLkAN8MKhtti8e-=hksg+oD3CDAUY6B9uh54zBLw@mail.gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Dec 13, 2018 at 12:15:51PM -0800, Dan Williams wrote:
> On Thu, Dec 13, 2018 at 12:09 PM Dr. David Alan Gilbert
> <dgilbert@redhat.com> wrote:
> >
> > * Dan Williams (dan.j.williams@intel.com) wrote:
> > > On Mon, Dec 10, 2018 at 9:22 AM Vivek Goyal <vgoyal@redhat.com> wrote:
> > > >
> > > > From: Stefan Hajnoczi <stefanha@redhat.com>
> > > >
> > > > Experimental QEMU code introduces an MMIO BAR for mapping portions of
> > > > files in the virtio-fs device.  Map this BAR so that FUSE DAX can access
> > > > file contents from the host page cache.
> > >
> > > FUSE DAX sounds terrifying, can you explain a bit more about what this is?
> >
> > We've got a guest running in QEMU, it sees an emulated PCI device;
> > that runs a FUSE protocol over virtio on that PCI device, but also has
> > a trick where via commands sent over the virtio queue associated with that device,
> > (fragments of) host files get mmap'd into the qemu virtual memory that corresponds
> > to the kvm slot exposed to the guest for that bar.
> >
> > The guest sees those chunks in that BAR, and thus you can read/write
> > to the host file by directly writing into that BAR.
> 
> Ok so it's all software emulated and there won't be hardware DMA
> initiated by the guest to that address?

That's my understanding.

> I.e. if the host file gets
> truncated / hole-punched the guest would just cause a refault and the
> filesystem could fill in the block,

Right

> or the guest is expected to die if
> the fault to the truncated file range results in SIGBUS.

Are you referring to the case where a file page is mapped in qemu and
another guest/process trucates that page and when qemu tries to access it it
will get SIGBUS. Have not tried it, will give it a try. Not sure what
happens when QEMU receives SIGBUS.

Having said that, this is not different from the case of one process
mapping a file and another process truncating the file and first process
getting SIGBUS, right?

Thanks
Vivek

> 
> > > > The DAX window is accessed by the fs/dax.c infrastructure and must have
> > > > struct pages (at least on x86).  Use devm_memremap_pages() to map the
> > > > DAX window PCI BAR and allocate struct page.
> > >
> > > PCI BAR space is not cache coherent,
> >
> > Note that no real PCI infrastructure is involved - this is all emulated
> > devices, backed by mmap'd files on the host qemu process.
> 
> Ok, terror level decreased.