All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Shuklin <george.shuklin@gmail.com>,
	"sandr8@gmail.com" <sandr8@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: a ton of kernel issues
Date: Wed, 14 Dec 2011 12:21:41 +0000	[thread overview]
Message-ID: <4EE894D5.5010107@citrix.com> (raw)
In-Reply-To: <1323864969.20077.405.camel@zakaz.uk.xensource.com>

On 14/12/11 12:16, Ian Campbell wrote:
> On Wed, 2011-12-14 at 07:25 +0000, Ian Campbell wrote:
>>
>> It controls precisely the behaviour you need! Try "maxmem=2048" and
>> "memory=1024" in your guest configuration, it should boot with 1G of
>> RAM and allow you to balloon to 2G and back. 
> 
> I take it back, there is indeed a bug in the PV ops kernel in this
> regard.
> 
> It works with xm/xend because they set the maximum reservation for
> guests to static-max on boot. xl (and, I think, xapi) instead set the
> maximum reservation to the current balloon target and change it
> dynamically as the target is changed (as a method of enforcing the
> targets). However the pvops kernel incorrectly uses the maximum
> reservation at boot to size the physical address space for guests.
> 
> The patch below fixes this.
> 
> Ian.
> 
> 8<-------------------------------------------------------------
> 
> From 649ca3b7ddca1cdda85c27e34f806f30484172ec Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Wed, 14 Dec 2011 12:00:38 +0000
> Subject: [PATCH] xen: only limit memory map to maximum reservation for domain 0.
> 
> d312ae878b6a "xen: use maximum reservation to limit amount of usable RAM"
> clamped the total amount of RAM to the current maximum reservation. This is
> correct for dom0 but is not correct for guest domains. In order to boot a guest
> "pre-ballooned" (e.g. with memory=1G but maxmem=2G) in order to allow for
> future memory expansion the guest must derive max_pfn from the e820 provided by
> the toolstack and not the current maximum reservation (which can reflect only
> the current maximum, not the guest lifetime max). The existing algorithm
> already behaves this correctly if we do not artificially limit the maximum
> number of pages for the guest case.
[...]
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: stable@kernel.org
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: David Vrabel <david.vrabel@citrix.com>

or Reviewed-by if that's more appropriate.

David

  reply	other threads:[~2011-12-14 12:21 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-12 21:44 a ton of kernel issues Tim Evers
2011-12-12 21:56 ` Konrad Rzeszutek Wilk
2011-12-14  9:00   ` Tim Evers
2011-12-15  1:25     ` Konrad Rzeszutek Wilk
2011-12-13  9:09 ` George Shuklin
2011-12-13 10:19   ` Alessandro Salvatori
2011-12-13 10:36     ` George Shuklin
2011-12-13 13:17       ` David Vrabel
2011-12-13 13:37         ` Ian Campbell
2011-12-13 20:59           ` George Shuklin
2011-12-13 22:30             ` Ian Campbell
2011-12-13 22:53               ` George Shuklin
2011-12-14  7:25                 ` Ian Campbell
2011-12-14 12:16                   ` Ian Campbell
2011-12-14 12:21                     ` David Vrabel [this message]
2011-12-14 13:11                     ` Jan Beulich
2011-12-14 13:48                       ` Ian Campbell
2011-12-14 17:44                     ` Konrad Rzeszutek Wilk
2011-12-15 12:45                     ` George Shuklin
2011-12-15 16:26                       ` Konrad Rzeszutek Wilk
2011-12-13 21:05         ` George Shuklin
2011-12-13 21:45           ` Konrad Rzeszutek Wilk
2011-12-14 12:28             ` David Vrabel
2011-12-14 16:57               ` Konrad Rzeszutek Wilk
2011-12-14  7:47           ` Fajar A. Nugraha
2011-12-14 18:40             ` George Shuklin
2011-12-13 14:18       ` Konrad Rzeszutek Wilk
2011-12-13 21:10         ` George Shuklin
2011-12-13 21:38           ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EE894D5.5010107@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=george.shuklin@gmail.com \
    --cc=konrad.wilk@oracle.com \
    --cc=sandr8@gmail.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.