On Thu, 03 Aug 2006 00:33:10 -0700
Zachary Amsden <zach at vmware.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.
The comment says "must". If that's true then printing a what-you-did-wrong
message and halting is appropriate.
But whatever. The issue is flagged and I'm happy to leave it in Jeremy's
lap.
