From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: Re: Proposed new "memory capacity claim" hypercall/feature Date: Mon, 5 Nov 2012 14:33:55 -0800 (PST) Message-ID: References: <50939A1502000078000A5F61@nat28.tlf.novell.com> <7481128d-3f65-4cc3-ad96-1d4e9cd25094@default> <20121104203532.GA11377@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20121104203532.GA11377@ocelot.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan Cc: Olaf Hering , Keir Fraser , IanCampbell , Konrad Wilk , George Dunlap , George Shuklin , Ian Jackson , xen-devel@lists.xen.org, DarioFaggioli , Jan Beulich , Kurt Hackel , Zhigang Wang List-Id: xen-devel@lists.xenproject.org > From: Tim Deegan [mailto:tim@xen.org] > Subject: Re: Proposed new "memory capacity claim" hypercall/feature Oops, missed an important part of your response... I'm glad I went back and reread it... > The claim hypercall _might_ fix (c) (if it could handle allocations that > need address-width limits or contiguous pages). I'm still looking into this part. It's my understanding (from Jan) that, post-dom0-launch, there are no known memory allocation paths that _require_ order>0 allocations. All of them attempt a larger allocation and gracefully fallback to (eventually) order==0 allocations. I've hacked some code in to the allocator to confirm this, though I'm not sure how to test the hypothesis exhaustively. For address-width limits, I suspect we are talking mostly or entirely about DMA in 32-bit PV domains? And/or PCI-passthrough? I'll look into it further, but if those are the principal cases, I'd have no problem documenting that the claim hypercall doesn't handle them and attempts to build such a domain might still fail slowly. At least unless/until someone decided to add any necessary special corner cases to the claim hypercall.