Re: [Xen-devel] [PATCH RFC v1 62/74] xen/pvshim: memory hotplug

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Jan 09, 2018 at 03:42:01AM -0700, Jan Beulich wrote:
> >>> On 04.01.18 at 14:06, <wei.liu2@xxxxxxxxxx> wrote:
> > +void pv_shim_online_memory(unsigned int nr, unsigned int order)
> > +{
> > +    struct page_info *page, *tmp;
> > +    PAGE_LIST_HEAD(list);
> > +
> > +    spin_lock(&balloon_lock);
> > +    page_list_for_each_safe ( page, tmp, &balloon )
> > +    {
> > +            if ( page->v.free.order != order )
> > +                continue;
> 
> Since guests (afaik) only ever balloon order-0 pages, this is fine
> for now. But it's insufficient in general - there's no point failing
> a request when there's no exact match available, but a higher
> order one is (which could be split).

Yes, that's right. Using order != 0 is likely to not work properly
given the lack of support for splitting higher order chunks.

I haven't implemented this because as you say there's no guest making
use of ti anyway. Let me add a TODO here.

> > @@ -993,6 +997,11 @@ long do_memory_op(unsigned long cmd, 
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >              return start_extent;
> >          }
> >  
> > +#ifdef CONFIG_X86
> > +        if ( pv_shim && op != XENMEM_decrease_reservation && !args.nr_done 
> > )
> > +            pv_shim_online_memory(args.nr_extents, args.extent_order);
> > +#endif
> > +
> >          switch ( op )
> >          {
> >          case XENMEM_increase_reservation:
> > @@ -1015,6 +1024,11 @@ long do_memory_op(unsigned long cmd, 
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >                  __HYPERVISOR_memory_op, "lh",
> >                  op | (rc << MEMOP_EXTENT_SHIFT), arg);
> >  
> > +#ifdef CONFIG_X86
> > +        if ( pv_shim && op == XENMEM_decrease_reservation )
> > +            pv_shim_offline_memory(args.nr_extents, args.extent_order);
> > +#endif
> 
> Looking at both of these changes - is it somewhere being made
> sure that shim containers won't boot in PoD mode?
> 
> For the latter change - is this correct when the operation has been
> preempted? I think you want to offline only the delta between
> start and args.nr_done.

AFAICT this function will only be called once, even when preempted.
On the online case it's only called when args.nr_done == 0, and in the
offline case it's only called after the work has been completely done.

Roger.

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