From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eWjMi-0004HR-Vo for qemu-devel@nongnu.org; Wed, 03 Jan 2018 08:45:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eWjMf-0003tR-R6 for qemu-devel@nongnu.org; Wed, 03 Jan 2018 08:45:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41006) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eWjMf-0003sQ-L7 for qemu-devel@nongnu.org; Wed, 03 Jan 2018 08:45:53 -0500 Date: Wed, 3 Jan 2018 11:45:28 -0200 From: Eduardo Habkost Message-ID: <20180103134528.GF6405@localhost.localdomain> References: <20171227065620.20889-1-haozhong.zhang@intel.com> <20180102175733-mutt-send-email-mst@kernel.org> <20180103031639.26c6iixwzs4auhxr@hz-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180103031639.26c6iixwzs4auhxr@hz-desktop> Subject: Re: [Qemu-devel] [PATCH] util/mmap-alloc: support MAP_SYNC in qemu_ram_mmap() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" , qemu-devel@nongnu.org, Xiao Guangrong , Igor Mammedov , Stefan Hajnoczi , Dan Williams On Wed, Jan 03, 2018 at 11:16:39AM +0800, Haozhong Zhang wrote: > On 01/02/18 18:02 +0200, Michael S. Tsirkin wrote: > > On Wed, Dec 27, 2017 at 02:56:20PM +0800, Haozhong Zhang wrote: > > > When a file supporting DAX is used as vNVDIMM backend, mmap it with > > > MAP_SYNC flag in addition can guarantee the persistence of guest write > > > to the backend file without other QEMU actions (e.g., periodic fsync() > > > by QEMU). > > > > > > By using MAP_SHARED_VALIDATE flag with MAP_SYNC, we can ensure mmap > > > with MAP_SYNC fails if MAP_SYNC is not supported by the kernel or the > > > backend file. On such failures, QEMU retries mmap without MAP_SYNC and > > > MAP_SHARED_VALIDATE. > > > > > > Signed-off-by: Haozhong Zhang > > > > If users rely on MAP_SYNC then don't you need to fail allocation > > if you can't use it? > > MAP_SYNC is supported since Linux kernel 4.15 and only needed for mmap > files on nvdimm. qemu_ram_mmap() has no way to check whether its > parameter 'fd' points to files on nvdimm, except by looking up > sysfs. However, accessing sysfs may be denied by certain SELinux > policies. > > The missing of MAP_SYNC should not affect the primary functionality of > vNVDIMM when using files on host nvdimm as backend, except the > guarantee of write persistence in case of qemu/host crash. > > We may check the kernel support of MAP_SYNC and the type of vNVDIMM > backend in some management utility (e.g., libvirt?), and deny to > launch QEMU if MAP_SYNC is not supported while files on host NVDIMM > are in use. Instead of making libvirt check if MAP_SYNC is supported and just hope it won't fail, it would be safer to let libvirt tell QEMU that MAP_SYNC must never fail. However, it looks like kernel 4.14 won't even fail if MAP_SYNC is specified. How exactly can userspace detect if MAP_SYNC is really supported? -- Eduardo