From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60826) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZlcy-0000Fa-5h for qemu-devel@nongnu.org; Tue, 07 May 2013 13:24:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZlct-0000nO-Gz for qemu-devel@nongnu.org; Tue, 07 May 2013 13:24:36 -0400 Received: from mx4-phx2.redhat.com ([209.132.183.25]:40327) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZlct-0000n8-9R for qemu-devel@nongnu.org; Tue, 07 May 2013 13:24:31 -0400 Date: Tue, 7 May 2013 13:24:26 -0400 (EDT) From: Paolo Bonzini Message-ID: <2000040416.7362082.1367947466362.JavaMail.root@redhat.com> In-Reply-To: References: <1367936238-12196-1-git-send-email-pbonzini@redhat.com> <1367936238-12196-9-git-send-email-pbonzini@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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: Peter Maydell , Alexander Graf Cc: aik@ozlabs.ru, jan kiszka , qemu-devel@nongnu.org, qemulist@gmail.com, Avi Kivity , stefanha@redhat.com, david@gibson.dropbear.id.au ----- 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 rad= ix tree to the actual address space size >=20 > 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 (contain= ers > > and aliases) are eliminated by the memory core, leaving only device reg= ions > > which have reasonable sizes. An IOMMU however cannot be eliminated by = the > > memory core, and may have an artificial size. >=20 > > +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 + section= .size, > > as_limit) > > + - section.offset_within_address_space; >=20 > 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? Paolo