Xen devel - Jun 2009 - Baffled by multipage_allocation_permitted()

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.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel