From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: [PATCH] x86/iommu: account for necessary allocations when calculating Dom0's initial allocation size Date: Tue, 14 Dec 2010 09:03:55 +0000 Message-ID: <4D07410B0200007800027C04@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartFBD7BCEB.0__=" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartFBD7BCEB.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline As of c/s 21812:e382656e4dcc, IOMMU related allocations for Dom0 happen only after it got all of its memory allocated, and hence the reserve (mainly for setting up its swiotlb) may get exhausted without accounting for the necessary allocations up front. While not precise, the estimate has been found to be within a couple of pages for the systems it got tested on. For the calculation to be reasonably correct, this depends on the patch titled "x86/iommu: don't map RAM holes above 4G" sent out yesterday. Signed-off-by: Jan Beulich --- a/xen/arch/x86/domain_build.c +++ b/xen/arch/x86/domain_build.c @@ -191,6 +191,15 @@ static unsigned long __init compute_dom0 if ( is_pv_32on64_domain(d) ) avail -=3D opt_dom0_max_vcpus - 1; =20 + /* Reserve memory for iommu_dom0_init() (rough estimate). */ + if ( iommu_enabled ) + { + unsigned int s; + + for ( s =3D 9; s < BITS_PER_LONG; s +=3D 9 ) + avail -=3D max_pdx >> s; + } + /* * If domain 0 allocation isn't specified, reserve 1/16th of = available * memory for things like DMA buffers. This reservation is clamped = to=20 --=__PartFBD7BCEB.0__= Content-Type: text/plain; name="x86-iommu-dom0-estimate.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-iommu-dom0-estimate.patch" As of c/s 21812:e382656e4dcc, IOMMU related allocations for Dom0=0Ahappen = only after it got all of its memory allocated, and hence the=0Areserve = (mainly for setting up its swiotlb) may get exhausted without=0Aaccounting = for the necessary allocations up front.=0A=0AWhile not precise, the = estimate has been found to be within a couple=0Aof pages for the systems = it got tested on.=0A=0AFor the calculation to be reasonably correct, this = depends on the=0Apatch titled "x86/iommu: don't map RAM holes above 4G" = sent out=0Ayesterday.=0A=0ASigned-off-by: Jan Beulich = =0A=0A--- a/xen/arch/x86/domain_build.c=0A+++ b/xen/arch/x86/domain_build.c= =0A@@ -191,6 +191,15 @@ static unsigned long __init compute_dom0=0A if = ( is_pv_32on64_domain(d) )=0A avail -=3D opt_dom0_max_vcpus - = 1;=0A =0A+ /* Reserve memory for iommu_dom0_init() (rough estimate). = */=0A+ if ( iommu_enabled )=0A+ {=0A+ unsigned int s;=0A+=0A+ = for ( s =3D 9; s < BITS_PER_LONG; s +=3D 9 )=0A+ avail = -=3D max_pdx >> s;=0A+ }=0A+=0A /*=0A * If domain 0 allocation = isn't specified, reserve 1/16th of available=0A * memory for things = like DMA buffers. This reservation is clamped to =0A --=__PartFBD7BCEB.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__PartFBD7BCEB.0__=--