[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 38/39] ARM: new VGIC: Allocate two pages for struct vcpu



On Thu, 22 Mar 2018, Julien Grall wrote:
> Hi Andre,
> 
> On 03/21/2018 04:32 PM, Andre Przywara wrote:
> > At the moment we allocate exactly one page for struct vcpu on ARM, also
> > have a check in place to prevent it growing beyond 4KB.
> > As the struct includes the state of all 32 private (per-VCPU) interrupts,
> > we are at 3840 bytes on arm64 at the moment already. Growing the per-IRQ
> > VGIC structure even slightly makes the VCPU quickly exceed the 4K limit.
> > The new VGIC will need more space per virtual IRQ. I spent a few hours
> > trying to trim this down, but couldn't get it below 4KB, even with the
> > nasty hacks piling up to save some bytes here and there.
> > It turns out that beyond efficiency, maybe, there is no real technical
> > reason this struct has to fit in one page, so lifting the limit to two
> > pages seems like the most pragmatic solution.
> > Restrict this to compiling with the new VGIC and for ARM64 only.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@xxxxxxxxxx>
> > ---
> > Changelog v2 ... v3:
> > - rework alloc_vcpu_struct() to avoid nasty #ifdef
> > 
> > Changelog v1 ... v2:
> > - confine change to new VGIC and ARM64 only
> > 
> >   xen/arch/arm/domain.c | 25 +++++++++++++++++++++----
> >   1 file changed, 21 insertions(+), 4 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index 9688e62f78..23bda3f7db 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -505,19 +505,36 @@ void dump_pageframe_info(struct domain *d)
> >     }
> >   +/*
> > + * The new VGIC has a bigger per-IRQ structure, so we need more than one
> > + * page on ARM64. Cowardly increase the limit in this case.
> > + */
> > +#if defined(CONFIG_NEW_VGIC) && defined(CONFIG_ARM_64)
> > +#define PAGES_PER_VCPU  2
> > +#else
> > +#define PAGES_PER_VCPU  1
> > +#endif
> > +
> >   struct vcpu *alloc_vcpu_struct(void)
> >   {
> >       struct vcpu *v;
> > -    BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE);
> > -    v = alloc_xenheap_pages(0, 0);
> > +
> > +    BUILD_BUG_ON(sizeof(*v) > PAGES_PER_VCPU * PAGE_SIZE);
> > +    v = alloc_xenheap_pages(get_order_from_pages(PAGES_PER_VCPU), 0);
> 
> I was suggesting to use get_order_from_pages(sizeof (...)) so if we end up to
> be smaller, you don't lose a page for nothing. But I am ok with that too and
> can revisit later. So:
> 
> Acked-by: Julien Grall <julien.grall@xxxxxxx>

That is actually a good suggestion, let's not lose track of it.

With that fix:

Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>



> >       if ( v != NULL )
> > -        clear_page(v);
> > +    {
> > +        unsigned int i;
> > +
> > +        for ( i = 0; i < PAGES_PER_VCPU; i++ )
> > +            clear_page((void *)v + i * PAGE_SIZE);
> > +    }
> > +
> >       return v;
> >   }
> >     void free_vcpu_struct(struct vcpu *v)
> >   {
> > -    free_xenheap_page(v);
> > +    free_xenheap_pages(v, get_order_from_pages(PAGES_PER_VCPU));
> >   }
> >     int vcpu_initialise(struct vcpu *v)
> > 
 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.