All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zachary Amsden <zach@vmware.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Jeremy Fitzhardinge <jeremy@xensource.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.osdl.org,
	xen-devel@lists.xensource.com, jeremy@goop.org,
	chrisw@sous-sol.org
Subject: Re: [patch 7/8] Add a bootparameter to reserve high linear address space.
Date: Thu, 03 Aug 2006 00:33:10 -0700	[thread overview]
Message-ID: <44D1A6B6.8040003@vmware.com> (raw)
In-Reply-To: <20060802231912.ed77f930.akpm@osdl.org>

Andrew Morton wrote:
> On Wed, 02 Aug 2006 17:25:17 -0700
> Jeremy Fitzhardinge <jeremy@xensource.com> wrote:
>
>   
>> +		/*
>> +		 * reservetop=size reserves a hole at the top of the kernel
>> +		 * address space which a hypervisor can load into later.
>> +		 * Needed for dynamically loaded hypervisors, so relocating
>> +		 * the fixmap can be done before paging initialization.
>> +		 * This hole must be a multiple of 4M.
>> +		 */
>> +		else if (!memcmp(from, "reservetop=", 11)) {
>> +			unsigned long reserve = memparse(from+11, &from);
>> +			reserve &= ~0x3fffff;
>> +			reserve_top_address(reserve);
>> +		}
>>     
>
> I assume that this argument will normally be passed in via the hypervisor
> rather than by human-entered information?
>
> In which case, perhaps a panic would be a more appropriate response to a
> non-multiple-of-4M.
>
> Either way, rounding the number down rather than up seems wrong...
>   

Agree on the rounding issue - but is a panic really correct?  Perhaps we 
should not round at all.

The presumption is actually that this is human or script entered 
information.  A runtime loaded hypervisor module has no way to tweak or 
toggle the boot parameters, as it hasn't yet been loaded.  It could be 
that a human operator wants to make room for it.  Giving the operator a 
panic is not the most friendly thing to do - logging the failure on 
module load is much nicer.  And such a runtime loaded hypervisor must be 
fully virtualizing anyway, so even if the argument is wrong and doesn't 
give the hypervisor enough space to load, no damage is done - the 
operator just resets the parameter and reboots.

Zach


WARNING: multiple messages have this Message-ID (diff)
From: Zachary Amsden <zach@vmware.com>
To: Andrew Morton <akpm@osdl.org>
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy@xensource.com>,
	linux-kernel@vger.kernel.org, chrisw@sous-sol.org,
	virtualization@lists.osdl.org
Subject: Re: [patch 7/8] Add a bootparameter to reserve high linear address space.
Date: Thu, 03 Aug 2006 00:33:10 -0700	[thread overview]
Message-ID: <44D1A6B6.8040003@vmware.com> (raw)
In-Reply-To: <20060802231912.ed77f930.akpm@osdl.org>

Andrew Morton wrote:
> On Wed, 02 Aug 2006 17:25:17 -0700
> Jeremy Fitzhardinge <jeremy@xensource.com> wrote:
>
>   
>> +		/*
>> +		 * reservetop=size reserves a hole at the top of the kernel
>> +		 * address space which a hypervisor can load into later.
>> +		 * Needed for dynamically loaded hypervisors, so relocating
>> +		 * the fixmap can be done before paging initialization.
>> +		 * This hole must be a multiple of 4M.
>> +		 */
>> +		else if (!memcmp(from, "reservetop=", 11)) {
>> +			unsigned long reserve = memparse(from+11, &from);
>> +			reserve &= ~0x3fffff;
>> +			reserve_top_address(reserve);
>> +		}
>>     
>
> I assume that this argument will normally be passed in via the hypervisor
> rather than by human-entered information?
>
> In which case, perhaps a panic would be a more appropriate response to a
> non-multiple-of-4M.
>
> Either way, rounding the number down rather than up seems wrong...
>   

Agree on the rounding issue - but is a panic really correct?  Perhaps we 
should not round at all.

The presumption is actually that this is human or script entered 
information.  A runtime loaded hypervisor module has no way to tweak or 
toggle the boot parameters, as it hasn't yet been loaded.  It could be 
that a human operator wants to make room for it.  Giving the operator a 
panic is not the most friendly thing to do - logging the failure on 
module load is much nicer.  And such a runtime loaded hypervisor must be 
fully virtualizing anyway, so even if the argument is wrong and doesn't 
give the hypervisor enough space to load, no damage is done - the 
operator just resets the parameter and reboots.

Zach

  reply	other threads:[~2006-08-03  7:33 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-03  0:25 [patch 0/8] Basic infrastructure patches for a paravirtualized kernel Jeremy Fitzhardinge
2006-08-03  0:25 ` Jeremy Fitzhardinge
2006-08-03  0:25 ` [patch 1/8] Remove locally-defined ldt structure in favour of standard type Jeremy Fitzhardinge
2006-08-03  0:25 ` [patch 2/8] Implement always-locked bit ops, for memory shared with an SMP hypervisor Jeremy Fitzhardinge
2006-08-03  0:25   ` Jeremy Fitzhardinge
2006-08-03  0:28   ` Christoph Lameter
2006-08-03  0:35     ` Jeremy Fitzhardinge
2006-08-03  1:06       ` Christoph Lameter
2006-08-03  1:18         ` Zachary Amsden
2006-08-03  1:18           ` Zachary Amsden
2006-08-03  1:25           ` Christoph Lameter
2006-08-03  3:55             ` Andi Kleen
2006-08-03  3:55               ` Andi Kleen
2006-08-03  4:25               ` Christoph Lameter
2006-08-03  4:47                 ` Andi Kleen
2006-08-03  4:47                   ` Andi Kleen
2006-08-03  2:45         ` Andi Kleen
2006-08-03  2:45           ` Andi Kleen
2006-08-03  4:27           ` Christoph Lameter
2006-08-03  4:49             ` Andi Kleen
2006-08-03  5:19               ` Christoph Lameter
2006-08-03  5:25                 ` Andi Kleen
2006-08-03  5:25                   ` Andi Kleen
2006-08-03  5:32                   ` Christoph Lameter
2006-08-03  5:39                     ` Andi Kleen
2006-08-03  5:39                       ` Andi Kleen
2006-08-03  5:54                       ` Christoph Lameter
2006-08-03  6:02                         ` Andi Kleen
2006-08-03 16:49                           ` Christoph Lameter
2006-08-03 17:18                             ` Chris Wright
2006-08-03 17:18                               ` Chris Wright
2006-08-04  0:47                             ` Andi Kleen
2006-08-04  2:16                               ` Christoph Lameter
2006-08-03  0:25 ` [patch 3/8] Allow a kernel to not be in ring 0 Jeremy Fitzhardinge
2006-08-03  0:25 ` [patch 4/8] Replace sensitive instructions with macros Jeremy Fitzhardinge
2006-08-03  0:25   ` Jeremy Fitzhardinge
2006-08-03  0:25 ` [patch 5/8] Roll all the cpuid asm into one __cpuid call Jeremy Fitzhardinge
2006-08-03  0:25 ` [patch 6/8] Make __FIXADDR_TOP variable to allow it to make space for a hypervisor Jeremy Fitzhardinge
2006-08-03  0:25 ` [patch 7/8] Add a bootparameter to reserve high linear address space Jeremy Fitzhardinge
1970-01-01  0:15   ` Pavel Machek
2006-08-07  2:10     ` Andi Kleen
2006-08-07  2:10       ` Andi Kleen
2010-05-04 23:37     ` Jeremy Fitzhardinge
2010-05-04 23:37       ` Jeremy Fitzhardinge
2006-08-03  6:19   ` Andrew Morton
2006-08-03  7:33     ` Zachary Amsden [this message]
2006-08-03  7:33       ` Zachary Amsden
2006-08-03  7:41       ` Andrew Morton
2006-08-03  8:58         ` Zachary Amsden
2006-08-03  8:58           ` Zachary Amsden
2006-08-05 21:58           ` Andrew Morton
2006-08-05 21:58             ` Andrew Morton
2006-08-05 22:52             ` Zachary Amsden
2006-08-05 22:52               ` Zachary Amsden
2006-08-05 23:17             ` Rusty Russell
2006-08-05 23:17               ` Rusty Russell
2006-08-06 22:00   ` Pavel Machek
2006-08-06 22:02   ` Pavel Machek
2006-08-07  9:12   ` Pavel Machek
2006-08-03  0:25 ` [patch 8/8] Put .note.* sections into a PT_NOTE segment in vmlinux Jeremy Fitzhardinge

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=44D1A6B6.8040003@vmware.com \
    --to=zach@vmware.com \
    --cc=akpm@osdl.org \
    --cc=chrisw@sous-sol.org \
    --cc=jeremy@goop.org \
    --cc=jeremy@xensource.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=virtualization@lists.osdl.org \
    --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.