Re: [Xen-devel] [PATCH v7 1/2] hypervisor: XENMEM_claim_pages (subop of existing) hypercall

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.11.12 at 19:11, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
> +unsigned long domain_increase_tot_pages(struct domain *d, unsigned long 
> pages)
> +{
> +    long dom_before, dom_after, dom_claimed, sys_before, sys_after;
> +
> +    ASSERT(spin_is_locked(&d->page_alloc_lock));
> +    if ( !d->unclaimed_pages )
> +        return d->tot_pages += pages;

So after the conditional adjustment above, I fail to see where
d->tot_pages would get adjusted in the code below. Which gets
me to ask ...

> +    spin_lock(&heap_lock);
> +    dom_before = d->unclaimed_pages;
> +    dom_after = dom_before - pages;
> +    if ( (dom_before > 0) && (dom_after < 0) )
> +        dom_claimed = 0;
> +    else
> +        dom_claimed = dom_after;
> +    sys_before = total_unclaimed_pages;
> +    sys_after = sys_before - (dom_before - dom_claimed);
> +    BUG_ON( (sys_before > 0) && (sys_after < 0) );
> +    total_unclaimed_pages = sys_after;
> +    d->unclaimed_pages = dom_claimed;
> +    spin_unlock(&heap_lock);
> +    return d->tot_pages;
> +}

...: Is there actually a strong reason why there needs to be an
"increase" and a "decrease" version of this, rather than just
having an "adjust" operation with a signed page count
parameter?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel