All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Rik van Riel <riel@redhat.com>
Cc: Pankaj Gupta <pagupta@redhat.com>,
	kvm@vger.kernel.org, qemu-devel@nongnu.org, pbonzini@redhat.com,
	kwolf@redhat.com, Haozhong Zhang <haozhong.zhang@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Xiao Guangrong <xiaoguangrong.eric@gmail.com>
Subject: Re: KVM "fake DAX" device flushing
Date: Fri, 12 May 2017 09:42:13 -0400	[thread overview]
Message-ID: <20170512134213.GB589@stefanha-x1.localdomain> (raw)
In-Reply-To: <1494538720.20270.35.camel@redhat.com>

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

On Thu, May 11, 2017 at 05:38:40PM -0400, Rik van Riel wrote:
> On Thu, 2017-05-11 at 14:17 -0400, Stefan Hajnoczi wrote:
> > On Wed, May 10, 2017 at 09:26:00PM +0530, Pankaj Gupta wrote:
> > > * For live migration use case, if host side backing file is 
> > >   shared storage, we need to flush the page cache for the disk 
> > >   image at the destination (new fadvise interface,
> > > FADV_INVALIDATE_CACHE?) 
> > >   before starting execution of the guest on the destination host.
> > 
> > Good point.  QEMU currently only supports live migration with
> > O_DIRECT.
> > I think the problem was that userspace cannot guarantee consistency
> > in
> > the general case.  If you find a solution to this problem for fake
> > NVDIMM then maybe the QEMU block layer can also begin supporting live
> > migration with buffered I/O.
> 
> I'll be happy to work with you on that, independently
> of Pankaj's project.
> 
> It looks like the fadvise system call could be extended
> pretty easily with an FADV_INVALIDATE_CACHE command, the
> other side of which can simply hook into the existing
> page cache invalidation code in the kernel.
> 
> Qemu will need to know whether the invalidation succeeded,
> but that is something we can test for pretty easily before
> returning to userspace.

Sounds great.  I will review the long discussions that took place on
qemu-devel about cache invalidation for live migration - just want to
make sure there were no other reasons why only O_DIRECT is supported :).

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Rik van Riel <riel@redhat.com>
Cc: Pankaj Gupta <pagupta@redhat.com>,
	kvm@vger.kernel.org, qemu-devel@nongnu.org, pbonzini@redhat.com,
	kwolf@redhat.com, Haozhong Zhang <haozhong.zhang@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Xiao Guangrong <xiaoguangrong.eric@gmail.com>
Subject: Re: [Qemu-devel] KVM "fake DAX" device flushing
Date: Fri, 12 May 2017 09:42:13 -0400	[thread overview]
Message-ID: <20170512134213.GB589@stefanha-x1.localdomain> (raw)
In-Reply-To: <1494538720.20270.35.camel@redhat.com>

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

On Thu, May 11, 2017 at 05:38:40PM -0400, Rik van Riel wrote:
> On Thu, 2017-05-11 at 14:17 -0400, Stefan Hajnoczi wrote:
> > On Wed, May 10, 2017 at 09:26:00PM +0530, Pankaj Gupta wrote:
> > > * For live migration use case, if host side backing file is 
> > >   shared storage, we need to flush the page cache for the disk 
> > >   image at the destination (new fadvise interface,
> > > FADV_INVALIDATE_CACHE?) 
> > >   before starting execution of the guest on the destination host.
> > 
> > Good point.  QEMU currently only supports live migration with
> > O_DIRECT.
> > I think the problem was that userspace cannot guarantee consistency
> > in
> > the general case.  If you find a solution to this problem for fake
> > NVDIMM then maybe the QEMU block layer can also begin supporting live
> > migration with buffered I/O.
> 
> I'll be happy to work with you on that, independently
> of Pankaj's project.
> 
> It looks like the fadvise system call could be extended
> pretty easily with an FADV_INVALIDATE_CACHE command, the
> other side of which can simply hook into the existing
> page cache invalidation code in the kernel.
> 
> Qemu will need to know whether the invalidation succeeded,
> but that is something we can test for pretty easily before
> returning to userspace.

Sounds great.  I will review the long discussions that took place on
qemu-devel about cache invalidation for live migration - just want to
make sure there were no other reasons why only O_DIRECT is supported :).

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  reply	other threads:[~2017-05-12 13:42 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-10 15:56 KVM "fake DAX" device flushing Pankaj Gupta
2017-05-10 15:56 ` [Qemu-devel] " Pankaj Gupta
2017-05-11 18:17 ` Stefan Hajnoczi
2017-05-11 18:17   ` [Qemu-devel] " Stefan Hajnoczi
2017-05-11 19:15   ` Dan Williams
2017-05-11 19:15     ` [Qemu-devel] " Dan Williams
2017-05-11 21:35     ` Rik van Riel
2017-05-11 21:35       ` [Qemu-devel] " Rik van Riel
2017-05-11 21:38   ` Rik van Riel
2017-05-11 21:38     ` [Qemu-devel] " Rik van Riel
2017-05-12 13:42     ` Stefan Hajnoczi [this message]
2017-05-12 13:42       ` Stefan Hajnoczi
2017-05-12 16:53       ` Kevin Wolf
2017-05-12 16:53         ` [Qemu-devel] " Kevin Wolf
2017-05-15  9:12         ` Stefan Hajnoczi
2017-05-12  6:56   ` Pankaj Gupta
2017-05-11 22:06 ` Dan Williams
2017-05-11 22:06   ` Dan Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170512134213.GB589@stefanha-x1.localdomain \
    --to=stefanha@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=haozhong.zhang@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwolf@redhat.com \
    --cc=pagupta@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=riel@redhat.com \
    --cc=xiaoguangrong.eric@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.