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

Re: [Xen-devel] Proposed new "memory capacity claim" hypercall/feature

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Thursday, November 08, 2012 6:49 AM
> To: Keir Fraser
> Cc: Olaf Hering; IanCampbell; George Dunlap; Ian Jackson; George Shuklin; 
> DarioFaggioli; xen-
> devel@xxxxxxxxxxxxx; Dan Magenheimer; Konrad Rzeszutek Wilk; Kurt Hackel; 
> Mukesh Rathor; Zhigang Wang;
> TimDeegan
> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
> >>> On 08.11.12 at 11:50, Keir Fraser <keir@xxxxxxx> wrote:
> > On 08/11/2012 09:47, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> >> The only thing that indeed is - on non-preemptible kernels - done
> >> only on exit to user mode is the eventual entering of the scheduler.
> >
> > That alone may still be an argument for restricting the batch size from the
> > toolstack?
> Yes, this clearly prohibits unlimited batches. But not being able to
> schedule should be less restrictive than not being able to run
> softirqs, so I'd still put under question whether the limit shouldn't
> be bumped.

Wait, please define unlimited.

I think we are in agreement from previous discussion that, to solve
the TOCTOU race, the heap_lock must be held for the entire allocation
for a domain creation.  True?

So unless the limit is "bumped" to handle the largest supported
physical memory size for a domain AND the allocation code in
the hypervisor is rewritten to hold the heap_lock while allocating
the entire extent, bumping the limit doesn't help the TOCTOU race,

Further, holding the heap_lock not only stops scheduling of
this pcpu, but also blocks other domains/pcpus from doing
any micro-allocations at all.  True?

Sorry if I am restating the obvious, but I am red-faced about
the huge-number-of-hypercalls mistake, so want to ensure if
I am understanding.


P.S. For PV domains, doesn't the toolstack already use a batch of up
to 2^20 pages?  (Or maybe I am misunderstanding/misreading the code
in arch_setup_meminit() in xc_dom_x86.c?)

Xen-devel mailing list



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