From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Christoph Egger" Subject: Re: [PATCH][XEN] construct_dom0: Initialize variable before use Date: Thu, 29 Nov 2007 14:37:24 +0100 Message-ID: <200711291437.24862.Christoph.Egger@amd.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Thursday 29 November 2007 14:28:00 Keir Fraser wrote: > On 29/11/07 13:02, "Christoph Egger" wrote: > > Without this fix, d->arch.physaddr_bitsize is 0 in > > domain_clamp_alloc_bitsize(). This causes all attempts to > > XENMEM_increase_reservation with bits > 0 to fail. More precisely, > > __alloc_domheap_pages() returns NULL. > > This impacts Xen heap allocation in general. > > Question: How did that work on Linux Dom0? > > Yes, that's pretty broken. It works for Linux because Linux allocates its > lowmem I/o pages (e.g., swiotlb) using the XENMEM_exchange command, and > that allocates the new memory anonymously in the first instance. This > defeats the bitsize clamp check (which is okay just now because our > truncation of the phsyical memory map to 166GB is sufficient to ensure th= at > compat domUs can address all memory). Thanks for clarification. NetBSD Dom0 failed when allocating DMA-safe memory above 4GB. Christoph =2D-=20 AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Gesch=E4ftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896 vertretungsberechtigter Komplement=E4r: AMD Saxony LLC (Sitz Wilmington, Delaware, USA) Gesch=E4ftsf=FChrer der AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy