From nobody Tue May 7 12:50:54 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1487957456972193.8816350975029; Fri, 24 Feb 2017 09:30:56 -0800 (PST) Received: from localhost ([::1]:38828 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chJhn-0005wL-Qn for importer@patchew.org; Fri, 24 Feb 2017 12:30:55 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33049) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chJeZ-0003N6-5k for qemu-devel@nongnu.org; Fri, 24 Feb 2017 12:27:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1chJeY-0005Js-6o for qemu-devel@nongnu.org; Fri, 24 Feb 2017 12:27:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49196) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1chJeY-0005Jk-0z for qemu-devel@nongnu.org; Fri, 24 Feb 2017 12:27:34 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 31EF58048F; Fri, 24 Feb 2017 17:27:34 +0000 (UTC) Received: from t460.redhat.com (ovpn-117-250.ams2.redhat.com [10.36.117.250]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1OHRVdF025881; Fri, 24 Feb 2017 12:27:32 -0500 From: "Daniel P. Berrange" To: qemu-devel@nongnu.org Date: Fri, 24 Feb 2017 17:27:14 +0000 Message-Id: <20170224172714.26026-1-berrange@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 24 Feb 2017 17:27:34 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH] os: don't corrupt pre-existing memory-backend data with prealloc X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jitendra Kolhe , Michal Privoznik , Stefan Hajnoczi , Paolo Bonzini Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" When using a memory-backend object with prealloc turned on, QEMU will memset() the first byte in every memory page to zero. While this might have been acceptable for memory backends associated with RAM, this corrupts application data for NVDIMMs. Instead of setting every page to zero, read the current byte value and then just write that same value back, so we are not corrupting the original data. Directly write the value instead of memset()ing it, since there's no benefit to memset for a single byte write. Signed-off-by: Daniel P. Berrange Reviewed-by: Stefan Hajnoczi --- NB, I have not tested performance of this, so no idea if this makes it better/worse/no-change. Would appreciate if Jitendra could repeat tests to see if it impacts scalability at all. util/oslib-posix.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/util/oslib-posix.c b/util/oslib-posix.c index 35012b9..2a5bb93 100644 --- a/util/oslib-posix.c +++ b/util/oslib-posix.c @@ -355,7 +355,20 @@ void os_mem_prealloc(int fd, char *area, size_t memory= , Error **errp) =20 /* MAP_POPULATE silently ignores failures */ for (i =3D 0; i < numpages; i++) { - memset(area + (hpagesize * i), 0, 1); + /* + * Read & write back the same value, so we don't + * corrupt existinng user/app data that might be + * stored. + * + * 'volatile' to stop compiler optimizing this away + * to a no-op + * + * TODO: get a better solution from kernel so we + * don't need to write at all so we don't cause + * wear on the storage backing the region... + */ + volatile char val =3D *(area + (hpagesize * i)); + *(area + (hpagesize * i)) =3D val; } } =20 --=20 2.9.3