From nobody Mon May 6 00:30:11 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 1488540815962240.31431776102124; Fri, 3 Mar 2017 03:33:35 -0800 (PST) Received: from localhost ([::1]:57302 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cjlSo-0001gl-B7 for importer@patchew.org; Fri, 03 Mar 2017 06:33:34 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57152) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cjlSL-0001gg-DD for qemu-devel@nongnu.org; Fri, 03 Mar 2017 06:33:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cjlSH-0004TW-Fc for qemu-devel@nongnu.org; Fri, 03 Mar 2017 06:33:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53178) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cjlSH-0004TL-AL for qemu-devel@nongnu.org; Fri, 03 Mar 2017 06:33:01 -0500 Received: from smtp.corp.redhat.com (int-mx16.intmail.prod.int.phx2.redhat.com [10.5.11.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4F8303A76BF; Fri, 3 Mar 2017 11:33:01 +0000 (UTC) Received: from t460.redhat.com (ovpn-117-177.ams2.redhat.com [10.36.117.177]) by smtp.corp.redhat.com (Postfix) with ESMTP id 93BDB30660; Fri, 3 Mar 2017 11:32:58 +0000 (UTC) From: "Daniel P. Berrange" To: qemu-devel@nongnu.org Date: Fri, 3 Mar 2017 11:32:55 +0000 Message-Id: <20170303113255.28262-1-berrange@redhat.com> X-Scanned-By: MIMEDefang 2.74 on 10.5.11.28 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Fri, 03 Mar 2017 11:33:01 +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 v3] 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: Andrea Arcangeli , Michal Privoznik , Jitendra Kolhe , 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: Andrea Arcangeli Reviewed-by: Stefan Hajnoczi --- Changed in v3: - Mark the target of the write as volatile, instead of the intermedia variable (Andrea) 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 f631464..544fb05 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 existing 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... + */ + char *page =3D area + (hpagesize * i); + *(volatile char *)page =3D *page; } } =20 --=20 2.9.3