From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Hajnoczi Subject: Re: KVM "fake DAX" device flushing Date: Fri, 12 May 2017 09:42:13 -0400 Message-ID: <20170512134213.GB589@stefanha-x1.localdomain> References: <1494431760-6455-1-git-send-email-pagupta@redhat.com> <20170511181703.GC8701@stefanha-x1.localdomain> <1494538720.20270.35.camel@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp" Cc: Pankaj Gupta , kvm@vger.kernel.org, qemu-devel@nongnu.org, pbonzini@redhat.com, kwolf@redhat.com, Haozhong Zhang , Dan Williams , Xiao Guangrong To: Rik van Riel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:60880 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754911AbdELNmQ (ORCPT ); Fri, 12 May 2017 09:42:16 -0400 Content-Disposition: inline In-Reply-To: <1494538720.20270.35.camel@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: --cvVnyQ+4j833TQvp Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=A0 > > > =A0 shared storage, we need to flush the page cache for the disk=A0 > > > =A0 image at the destination (new fadvise interface, > > > FADV_INVALIDATE_CACHE?)=A0 > > > =A0 before starting execution of the guest on the destination host. > >=20 > > Good point.=A0=A0QEMU currently only supports live migration with > > O_DIRECT. > > I think the problem was that userspace cannot guarantee consistency > > in > > the general case.=A0=A0If 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. >=20 > I'll be happy to work with you on that, independently > of Pankaj's project. >=20 > 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. >=20 > 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 --cvVnyQ+4j833TQvp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJZFbu1AAoJEJykq7OBq3PITGUH/ir6ZhRWMditYdnRDGP8XBUy Y2D6wjZ0sN0PD8Wuip6vIqkG2TJbY8ibajP8eCaQWr6kUrW51bM3Wzz0nHkLA9PL JOkdN035bJwPEY2b6IbjDdUfbiFEHOXGzX5CcPzEalXTMViO1y2GZfiqwOHk+atY jdt/tcUjA+ApsOhtAhoZnMHz/1VLgrSkkKUlvXCpe/IyATWWT23Zryc9WuKnsxPq 4++CGecoGhI3PrtO68U+z+VKcIRfV1FW2prYHRx4KykUrBDPEIj5BTfUu2wjN7Jh Msa0V+dYixPahJcymOvnQc5D0vFqfkTpCwzWyfrbD+YAEth18j+Go9trcQJcg8k= =3Yhz -----END PGP SIGNATURE----- --cvVnyQ+4j833TQvp-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60375) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d9Apu-0004Y3-FU for qemu-devel@nongnu.org; Fri, 12 May 2017 09:42:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d9Apn-0006Gu-F6 for qemu-devel@nongnu.org; Fri, 12 May 2017 09:42:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57546) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d9Apn-0006GO-59 for qemu-devel@nongnu.org; Fri, 12 May 2017 09:42:19 -0400 Date: Fri, 12 May 2017 09:42:13 -0400 From: Stefan Hajnoczi Message-ID: <20170512134213.GB589@stefanha-x1.localdomain> References: <1494431760-6455-1-git-send-email-pagupta@redhat.com> <20170511181703.GC8701@stefanha-x1.localdomain> <1494538720.20270.35.camel@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline In-Reply-To: <1494538720.20270.35.camel@redhat.com> Subject: Re: [Qemu-devel] KVM "fake DAX" device flushing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rik van Riel Cc: Pankaj Gupta , kvm@vger.kernel.org, qemu-devel@nongnu.org, pbonzini@redhat.com, kwolf@redhat.com, Haozhong Zhang , Dan Williams , Xiao Guangrong --cvVnyQ+4j833TQvp Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=A0 > > > =A0 shared storage, we need to flush the page cache for the disk=A0 > > > =A0 image at the destination (new fadvise interface, > > > FADV_INVALIDATE_CACHE?)=A0 > > > =A0 before starting execution of the guest on the destination host. > >=20 > > Good point.=A0=A0QEMU currently only supports live migration with > > O_DIRECT. > > I think the problem was that userspace cannot guarantee consistency > > in > > the general case.=A0=A0If 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. >=20 > I'll be happy to work with you on that, independently > of Pankaj's project. >=20 > 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. >=20 > 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 --cvVnyQ+4j833TQvp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJZFbu1AAoJEJykq7OBq3PITGUH/ir6ZhRWMditYdnRDGP8XBUy Y2D6wjZ0sN0PD8Wuip6vIqkG2TJbY8ibajP8eCaQWr6kUrW51bM3Wzz0nHkLA9PL JOkdN035bJwPEY2b6IbjDdUfbiFEHOXGzX5CcPzEalXTMViO1y2GZfiqwOHk+atY jdt/tcUjA+ApsOhtAhoZnMHz/1VLgrSkkKUlvXCpe/IyATWWT23Zryc9WuKnsxPq 4++CGecoGhI3PrtO68U+z+VKcIRfV1FW2prYHRx4KykUrBDPEIj5BTfUu2wjN7Jh Msa0V+dYixPahJcymOvnQc5D0vFqfkTpCwzWyfrbD+YAEth18j+Go9trcQJcg8k= =3Yhz -----END PGP SIGNATURE----- --cvVnyQ+4j833TQvp--