From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZlps-0001by-If for qemu-devel@nongnu.org; Tue, 07 May 2013 13:37:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZlpq-0005ao-79 for qemu-devel@nongnu.org; Tue, 07 May 2013 13:37:56 -0400 Received: from cantor2.suse.de ([195.135.220.15]:52141 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZlpp-0005aW-Uf for qemu-devel@nongnu.org; Tue, 07 May 2013 13:37:54 -0400 Message-ID: <51893BEC.6020805@suse.de> Date: Tue, 07 May 2013 19:37:48 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1367936238-12196-1-git-send-email-pbonzini@redhat.com> <1367936238-12196-9-git-send-email-pbonzini@redhat.com> <2000040416.7362082.1367947466362.JavaMail.root@redhat.com> In-Reply-To: <2000040416.7362082.1367947466362.JavaMail.root@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 08/40] memory: limit sections in the radix tree to the actual address space size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , aik@ozlabs.ru, jan kiszka , qemulist@gmail.com, qemu-devel@nongnu.org, Avi Kivity , stefanha@redhat.com, david@gibson.dropbear.id.au On 05/07/2013 07:24 PM, Paolo Bonzini wrote: > > ----- Messaggio originale ----- >> Da: "Peter Maydell" >> A: "Paolo Bonzini" >> Cc: qemu-devel@nongnu.org, aik@ozlabs.ru, "jan kiszka", qemulist@gmail.com, "Avi Kivity" >> , stefanha@redhat.com, david@gibson.dropbear.id.= au >> Inviato: Marted=C3=AC, 7 maggio 2013 19:13:16 >> Oggetto: Re: [Qemu-devel] [PATCH 08/40] memory: limit sections in the = radix tree to the actual address space size >> >> On 7 May 2013 15:16, Paolo Bonzini wrote: >>> From: Avi Kivity >>> >>> The radix tree is statically sized to fit TARGET_PHYS_ADDR_SPACE_BITS= . >>> If a larger memory region is registered, it will overflow. >>> >>> Fix by limiting any section in the radix tree to the supported size. >>> >>> This problem was not observed earlier since artificial regions (conta= iners >>> and aliases) are eliminated by the memory core, leaving only device r= egions >>> which have reasonable sizes. An IOMMU however cannot be eliminated b= y the >>> memory core, and may have an artificial size. >>> +static MemoryRegionSection limit(MemoryRegionSection section) >>> +{ >>> + unsigned practical_as_bits =3D MIN(TARGET_PHYS_ADDR_SPACE_BITS, = 62); >>> + hwaddr as_limit; >>> + >>> + as_limit =3D (hwaddr)1<< practical_as_bits; >>> + >>> + section.size =3D MIN(section.offset_within_address_space + secti= on.size, >>> as_limit) >>> + - section.offset_within_address_space; >> Isn't this going to give you a negative size for a section >> which is up at the top of physical memory in a CPU with >> a 63 or 64 bit physical address space? [ie one where the >> section.offset_within_address_space> as_limit] > Yes, this assumes that TARGET_PHYS_ADDR_SPACE_BITS< 62 in practice, > and that only artificial regions are larger. But perhaps we should > have a BUILD_BUG_ON instead of the MIN. > > The only target that has a bigger _physical_ address space is s390. > Alex, is that definition correct? IIRC s390x can handle up to 64 bit of physical address space from its=20 page tables. But we never use that much, so it's perfectly fine for me=20 if you just decrease the value. Alex