Baffled by multipage_allocation_permitted()

Baffled by multipage_allocation_permitted()

[Dave McCracken]

I have completed changes that allow me to create/save/restore domains 
allocated with 2M pages and run kernels with hugepage support.  This all 
appears to work fine.

However, while teaching the balloon driver to work in 2M page sizes, I 
suddenly had the multipage_allocation_permitted() macro in the hypervisor 
start failing.  This macro has the definition:

#define multipage_allocation_permitted(d)   \
   (!rangeset_is_empty((d)->iomem_caps) || \
    !rangeset_is_empty((d)->arch.ioport_caps))

I had never tracked down the significance of this macro since it didn't appear 
to be an issue.  Now it's suddenly denying me the ability to work in 2M pages.

What is this macro trying to achieve?  Why is it necessary?  Is there any 
compelling reason we can't just remove it and allow multipage allocations from 
any domain?

Thanks,
Dave McCracken
Oracle Corp.

Re: Baffled by multipage_allocation_permitted()

[Keir Fraser]

On 15/06/2009 22:44, "Dave McCracken" <dcm@mccr.org> wrote:

> #define multipage_allocation_permitted(d)   \
>    (!rangeset_is_empty((d)->iomem_caps) || \
>     !rangeset_is_empty((d)->arch.ioport_caps))
> 
> I had never tracked down the significance of this macro since it didn't appear
> to be an issue.  Now it's suddenly denying me the ability to work in 2M pages.
> 
> What is this macro trying to achieve?  Why is it necessary?  Is there any
> compelling reason we can't just remove it and allow multipage allocations from
> any domain?

We can just get rid of it I think. There are arguably worse other things we
already allow, like any guest can allocate low memory by specifying a small
value of XENMEMF_address_bits().

 -- Keir

Re: Baffled by multipage_allocation_permitted()

[Jan Beulich]

>>> Keir Fraser <keir.fraser@eu.citrix.com> 15.06.09 23:57 >>>
>On 15/06/2009 22:44, "Dave McCracken" <dcm@mccr.org> wrote:
>
>> #define multipage_allocation_permitted(d)   \
>>    (!rangeset_is_empty((d)->iomem_caps) || \
>>     !rangeset_is_empty((d)->arch.ioport_caps))
>> 
>> I had never tracked down the significance of this macro since it didn't appear
>> to be an issue.  Now it's suddenly denying me the ability to work in 2M pages.
>> 
>> What is this macro trying to achieve?  Why is it necessary?  Is there any
>> compelling reason we can't just remove it and allow multipage allocations from
>> any domain?
>
>We can just get rid of it I think. There are arguably worse other things we
>already allow, like any guest can allocate low memory by specifying a small
>value of XENMEMF_address_bits().

Wouldn't it be better to tighten things rather than relaxing them?

Jan

Re: Baffled by multipage_allocation_permitted()

[Keir Fraser]

On 16/06/2009 10:19, "Jan Beulich" <JBeulich@novell.com> wrote:

>> We can just get rid of it I think. There are arguably worse other things we
>> already allow, like any guest can allocate low memory by specifying a small
>> value of XENMEMF_address_bits().
> 
> Wouldn't it be better to tighten things rather than relaxing them?

It'll need policy to be expressed and pushed down from the toolstack
somehow. Noone's really thought about it too much. In this case I think I
will keep the checking macro actually, and simply disallow allocations
greater than order-9 (2MB superpage) unless the domain has direct hardware
access capability.

 -- Keir

Re: Baffled by multipage_allocation_permitted()

[Dave McCracken]

On Tuesday 16 June 2009, Keir Fraser wrote:
> On 16/06/2009 10:19, "Jan Beulich" <JBeulich@novell.com> wrote:
> >> We can just get rid of it I think. There are arguably worse other things
> >> we already allow, like any guest can allocate low memory by specifying a
> >> small value of XENMEMF_address_bits().
> >
> > Wouldn't it be better to tighten things rather than relaxing them?
>
> It'll need policy to be expressed and pushed down from the toolstack
> somehow. Noone's really thought about it too much. In this case I think I
> will keep the checking macro actually, and simply disallow allocations
> greater than order-9 (2MB superpage) unless the domain has direct hardware
> access capability.

Thanks for the change.  That resolves my problem.

Out of curiosity, why is it necessary to restrict the size of multipage 
allocations at all?  I'd think the memory size limits would adequately protect 
against any guest going wild with it.  What harm could come from, for example, 
a guest asking for a 16M contiguous page?  I don't know of any current need 
for such a thing.  I'm just wondering why we restrict it.

Thanks,
Dave McCracken
Oracle Corp.

Re: Baffled by multipage_allocation_permitted()

[Keir Fraser]

On 16/06/2009 14:10, "Dave McCracken" <dcm@mccr.org> wrote:

> Thanks for the change.  That resolves my problem.
> 
> Out of curiosity, why is it necessary to restrict the size of multipage
> allocations at all?  I'd think the memory size limits would adequately protect
> against any guest going wild with it.  What harm could come from, for example,
> a guest asking for a 16M contiguous page?  I don't know of any current need
> for such a thing.  I'm just wondering why we restrict it.

Such regions could be a precious resource when driving some hardware devices
which communicate via large contiguous memory areas. As I said, we haven't
thought about it too hard, so it may indeed be sensible to relax this
further in future.

 -- Keir

Re: Baffled by multipage_allocation_permitted()

[Jan Beulich]

>>> Dave McCracken <dcm@mccr.org> 16.06.09 15:10 >>>
>Out of curiosity, why is it necessary to restrict the size of multipage 
>allocations at all?  I'd think the memory size limits would adequately protect 
>against any guest going wild with it.  What harm could come from, for example, 
>a guest asking for a 16M contiguous page?  I don't know of any current need 
>for such a thing.  I'm just wondering why we restrict it.

Because contiguous memory is a more precious resource than just individual
pages, and allocations strictly needing multiple contiguous pages should not
fail because of a random guest doing odd things.

Jan