Re: [libvirt] [PATCH 2/3] docs, conf, schema: add support for shared memory mapping

On Mon, Sep 15, 2014 at 01:19:25PM +0200, Martin Kletzander wrote: > On Mon, Sep 15, 2014 at 10:20:01AM +0100, Daniel P. Berrange wrote: > >On Mon, Sep 15, 2014 at 09:47:45AM +0200, Martin Kletzander wrote: > >>On Wed, Sep 10, 2014 at 04:46:27PM +0100, Daniel P. Berrange wrote: > >>>On Wed, Sep 10, 2014 at 05:36:58PM +0200, Ján Tomko wrote: > >>>>On 09/08/2014 01:40 PM, Martin Kletzander wrote: > >>>>> Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com&gt; > >>>>> --- > >>>>> docs/formatdomain.html.in | 7 +++- > >>>>> docs/schemas/domaincommon.rng | 5 +++ > >>>>> src/conf/cpu_conf.c | 25 +++++++++++- > >>>>> src/conf/cpu_conf.h | 7 ++-- > >>>>> .../qemuxml2argv-cpu-numa-memshared.xml | 28 ++++++++++++++ > >>>>> .../qemuxml2argv-hugepages-shared.xml | 45 ++++++++++++++++++++++ > >>>>> tests/qemuxml2xmltest.c | 2 + > >>>>> 7 files changed, 113 insertions(+), 6 deletions(-) > >>>>> create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-numa-memshared.xml > >>>>> create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-hugepages-shared.xml > >>>>> > >>>>> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in > >>>>> index 94236dd..b284d6e 100644 > >>>>> --- a/docs/formatdomain.html.in > >>>>> +++ b/docs/formatdomain.html.in > >>>>> @@ -1105,7 +1105,7 @@ > >>>>> ... > >>>>> &lt;numa&gt; > >>>>> &lt;cell id='0' cpus='0-3' memory='512000'/&gt; > >>>>> - &lt;cell id='1' cpus='4-7' memory='512000'/&gt; > >>>>> + &lt;cell id='1' cpus='4-7' memory='512000' memShared='on'/&gt; > >>>> > >>>>I wonder if "shared='on'" would be enough, avoiding the need for a multi-word > >>>>attribute. > >>> > >>>Or how about access="shared|private" ? > >>> > >> > >>I prepended the "mem" so that it is visible that it has something to > >>do with the memory, not the whole node. But I'm OK with pushing > >>shared= as well. Using access= seems too ambiguously worded to me, > >>although if most of you agree... > > > >Sure, memAccess is fine with me. > > > > Is there any possibility of that option having another value (in the > future)? Otherwise shared= seems more appropriate to me. Let's see > what others think, so I can finally get rid of this problem :) I prefer the approach of having values reflect the usage, as 'shared' vs 'private' for the value is clearer than 'on' vs 'off' IMHO.