Re: [Xen-devel] [PATCH] domain_create: honour global grant/maptrack frame limits...

From: "Durrant, Paul" <pdurrant@amazon.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] domain_create: honour global grant/maptrack frame limits...
Date: Wed, 13 Nov 2019 14:11:48 +0000	[thread overview]
Message-ID: <824ceb5657bd4630a808929863131d4e@EX13D32EUC003.ant.amazon.com> (raw)
In-Reply-To: <ef11eba3-4643-fa7f-2598-6a9a04c2ec77@citrix.com>

> -----Original Message-----
> From: Andrew Cooper <andrew.cooper3@citrix.com>
> Sent: 13 November 2019 14:05
> To: Durrant, Paul <pdurrant@amazon.com>; xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH] domain_create: honour global
> grant/maptrack frame limits...
> 
> On 13/11/2019 13:47, Paul Durrant wrote:
> > ...when their values are larger than the per-domain configured limits.
> >
> > Signed-off-by: Paul Durrant <pdurrant@amazon.com>
> > ---
> > After mining through commits it is still unclear to me exactly when Xen
> > stopped honouring the global values, but I really think this commit
> should
> > be back-ported to stable trees as it was a behavioural change that can
> > cause domUs to fail in non-obvious ways.
> 
> -1.  Overriding toolstack settings like this is the same kind of "bad"
> as silently converting HAP => Shadow.
> 
> In particular, this breaks one of points of the original per-domain work
> to deliberately allow stub xenstored to be configured with tiny
> grant/maptrack tables.

Ok, but IMO subtly breaking domUs in the process is not really acceptable behaviour.

> 
> You also break the setting of these parameters in xl.conf.

No I don't. xl.conf can still increase values over the command line.

> 
> I'm not defending how the interface changed subtly/unexpected; that was
> bad and we should have done better, but this change is just as bad in
> the opposite direction.
> 
> The way to fix this is to plumb the Xen default parameters though so
> that, in the absence of any explicit configuration (vm.cfg or xl.conf),
> libxl can then use "xen cmdline" as a source of configuration, before
> falling back to hardcoded numbers.
> 

I agree that is the best way to fix it, but not so easy to backport. So my proposal (via email a few days ago) was that regressions are fixed immediately in this way and then a *proper* fix is done moving forward, which I shall base upon Juergen's patches which should allow easy retrieval of the command line values.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel