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

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Subject: Re: [RFC/PATCH v6 1/2] hypervisor: XENMEM_claim_pages (subop of 
> existing) hypercall
> 
> >>> On 20.11.12 at 18:04, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
> > This is patch 1of2 of a sixth cut of the patch of the proposed
> > XENMEM_claim_pages hypercall/subop, taking into account review
> > feedback from Jan and Keir and IanC and Matthew Daley, plus some
> > fixes found via runtime debugging (using printk and privcmd only).
> >
> > v5->v6:
> > - Fix post-inc problem [mattjd]
> 
> I continue to miss an expiry mechanism for claims; as said before
> I don't think these should be held indefinitely.

Do you mean some kind of time-based expiry?

The simple use model I have in mind results in toolstack
changes as follows:

Current:
- call populate_physmap repeatedly to achieve mem=N memory
- if any populate_physmap call fails, report -ENOMEM up the stack
- memory is held until domain dies or the toolstack decreases it

Proposed:
- call claim for mem=N amount of memory
- if claim succeeds:
    call populate_physmap repeatedly to achieve mem=N memory (failsafe)
  else
    report -ENOMEM up the stack
- claim is held until mem=N is achieved or the domain dies or
   the toolstack changes it to 0
- memory is held until domain dies or the toolstack decreases it

In both cases, the memory is held "indefinitely" so I'm
not sure I see why a claim would need a time-based expiry
when a populate_physmap doesn't.  A claim is really just
a "soft" version of a populate_physmap where the quantity
of pages are (atomically) assigned to the domain but the specific
physical pageframes are (non-atomically) assigned later.

Does that make sense?

Thanks,
Dan

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