From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH 4/4] x86/PoD: Command line option to
 prohibit any PoD operations
Date: Mon, 2 Nov 2015 14:32:03 +0000
Message-ID: <1446474723.3088.54.camel@citrix.com>
References: <1446230022-8349-1-git-send-email-andrew.cooper3@citrix.com>
	<1446230022-8349-5-git-send-email-andrew.cooper3@citrix.com>
	<563778D902000078000B0C2C@prv-mh.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <563778D902000078000B0C2C@prv-mh.provo.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On Mon, 2015-11-02 at 06:53 -0700, Jan Beulich wrote:
> > > > On 30.10.15 at 19:33, <andrew.cooper3@citrix.com> wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -92,6 +92,9 @@ unsigned long __section(".bss.page_aligned")
> >  static bool_t __initdata opt_hap_enabled = 1;
> >  boolean_param("hap", opt_hap_enabled);
> >  
> > +bool_t opt_pod_enabled = 1;
> 
> __read_mostly?
> 
> > --- a/xen/common/memory.c
> > +++ b/xen/common/memory.c
> > @@ -818,6 +818,10 @@ long do_memory_op(unsigned long cmd,
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >          if ( unlikely(start_extent >= reservation.nr_extents) )
> >              return start_extent;
> >  
> > +        if ( unlikely(!opt_pod_enabled) &&
> > +             (reservation.mem_flags & XENMEMF_populate_on_demand) )
> > +            return start_extent;
> 
> A few lines down we can see that XENMEMF_populate_on_demand
> gets honored only for XENMEM_populate_physmap. Perhaps you
> shouldn't fail the other two which ignore the flag anyway?

Setting an unexpected flag surely ought to be an error? Admittedly that
particular ship may have sailed WRT this public ABI.

>  And
> perhaps you should also fold this into the existing check?
> 
> Also I don't think this is going to build on ARM.

Because opt_pod_enabled is on x86 only, I suppose.

I wouldn't be averse to a "const bool_t opt_pod_enabled = 0" in some
convenient place, seems better than the alternative of ifdefs around here.

Ian.