From nobody Mon Feb 9 10:57:37 2026
Delivered-To: importer@patchew.org
Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.25
as permitted sender) client-ip=209.132.183.25;
envelope-from=libvir-list-bounces@redhat.com; helo=mx4-phx2.redhat.com;
Authentication-Results: mx.zoho.com;
spf=pass (zoho.com: domain of redhat.com designates 209.132.183.25 as
permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com;
Return-Path:
Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by
mx.zohomail.com
with SMTPS id 1487840811576281.6294835859933;
Thu, 23 Feb 2017 01:06:51 -0800 (PST)
Received: from lists01.pubmisc.prod.ext.phx2.redhat.com
(lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33])
by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id v1N93SiQ000724;
Thu, 23 Feb 2017 04:03:29 -0500
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
id v1N93P8B009845 for ;
Thu, 23 Feb 2017 04:03:25 -0500
Received: from moe.brq.redhat.com (dhcp129-131.brq.redhat.com [10.34.129.131])
by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with
ESMTP id v1N93H6j012322; Thu, 23 Feb 2017 04:03:24 -0500
From: Michal Privoznik
To: libvir-list@redhat.com
Date: Thu, 23 Feb 2017 10:02:49 +0100
Message-Id:
In-Reply-To:
References:
In-Reply-To:
References:
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-loop: libvir-list@redhat.com
Subject: [libvirt] [PATCH 06/14] conf: Introduce @access to
X-BeenThere: libvir-list@redhat.com
X-Mailman-Version: 2.1.12
Precedence: junk
List-Id: Development discussions about the libvirt library & tools
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Sender: libvir-list-bounces@redhat.com
Errors-To: libvir-list-bounces@redhat.com
X-ZohoMail: RSF_0 Z_629925259 SPT_0
Content-Type: text/plain; charset="utf-8"
Now that NVDIMM has found its way into libvirt, users might want
to fine tune some settings for each module separately. One such
setting is 'share=3Don|off' for the memory-backend-file object.
This setting - just like its name suggest already - enables
sharing the nvdimm module with other applications. Under the hood
it controls whether qemu mmaps() the file as MAP_PRIVATE or
MAP_SHARED.
Yet again, we have such config knob in domain XML, but it's just
an attribute to numa . This does not give fine enough
tuning on per-memdevice basis so we need to have the attribute
for each device too.
Signed-off-by: Michal Privoznik
---
docs/formatdomain.html.in | 15 ++++++-
docs/schemas/domaincommon.rng | 8 ++++
src/conf/domain_conf.c | 15 ++++++-
src/conf/domain_conf.h | 2 +
.../qemuxml2argv-memory-hotplug-nvdimm-access.xml | 49 ++++++++++++++++++=
++++
5 files changed, 86 insertions(+), 3 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-memory-hotplug-nvdi=
mm-access.xml
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index b76905cdc..00c0df2ce 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -1406,7 +1406,7 @@
Since 1.2.9 the optional attribute
memAccess can control whether the memory is to be
mapped as "shared" or "private". This is valid only for
- hugepages-backed memory.
+ hugepages-backed memory and nvdimm modules.
+ Then there is optional attribute access
+ (Since 3.1.0) that allows
+ uses to fine tune mapping of the memory on per module
+ basis. Values are the same as for numa <cell/>:
+ shared and private.
+