[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: "Durrant, Paul" <pdurrant@xxxxxxxxxx>
  • Date: Wed, 13 Nov 2019 14:11:48 +0000
  • Accept-language: en-GB, en-US
  • Delivery-date: Wed, 13 Nov 2019 14:12:00 +0000
  • Ironport-sdr: Bf4i+Ka76O37RGqPa+sJ/bleA2nkHGeIio1BkQfklaBvovP9AhTDwD9OWUWP8aQ93vR49TS1yQ VMf5kDk42xlw==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVmijmkXyX3G407UypjXtu2UKVEKeJImIAgAAA7EA=
  • Thread-topic: [Xen-devel] [PATCH] domain_create: honour global grant/maptrack frame limits...

> -----Original Message-----
> From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Sent: 13 November 2019 14:05
> To: Durrant, Paul <pdurrant@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxx>
> > ---
> > 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.