From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: Linux Xen balloon driver "minimum target" Date: Fri, 18 Jun 2010 08:24:39 -0700 (PDT) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com, Dave Scott , Jeremy Fitzhardinge , Jan Beulich Cc: George Dunlap , George Shuklin , Keir Fraser List-Id: xen-devel@lists.xenproject.org As recently re-pointed out by George Shuklin: http://lists.xensource.com/archives/html/xen-devel/2010-06/msg00849.html=20 with brief reply commentary by Keir: http://lists.xensource.com/archives/html/xen-devel/2010-06/msg00875.html=20 the Xen ballooning code in many distros contains a "minimum target" to allow a domain to protect itself against silly and accidental balloon settings, it being frightfully easy for a typo or misunderstanding (e.g. an integer intended to represent MB but, oops, the value should be given in KB) to result in a guest or dom0 crash. This code originated from Novell about two years ago: http://lists.xensource.com/archives/html/xen-devel/2008-04/msg00143.html=20 and, in my experience, eliminated frequent bug reports that "xm memset" resulted in unexpected crashes. This minimum target is a bit over-conservative, especially on machines with 1GB-2GB of memory. Also, the "logarithmic function" is applied to different values in different kernels, so is in some cases a function of the config file's "maxmem" and in some cases a function of "memory". Because the variations of this code are broad (and, in upstream Linux, non-existent), posting a patch doesn't solve the problem. So instead, I thought I would open a discussion with my opinions and "solution". We'll keep this on xen-devel for now, but perhaps should open the discussion to xen-users as well. I am in favor of keeping the code AND inserting some form of it in the upstream balloon driver. There are two forms of policy it enforces: (1) don't let an admin do something REALLY stupid; and (2) "stupid" is dependent on the amount of guest physical memory. While I don't much like (2), I don't see a way one can get (1) without (2). As a partial answer, in my balloon driver implementation (to support self-ballooning) I added an additional proc/sysfs variable "min_target_kb". This is set during init to the result of the "minimum target" algorithm and, once set, is used as the minimum allowed ballooning target. BUT this variable is writable, allowing the safety latch to be overridden. As a result, a system admin must shoot himself in the foot before accidentally shooting himself in the head. Clearly this is still not an ideal solution, but it works for me. Comments?