----- Messaggio originale ----- > Da: "Peter Maydell" <peter.mayd...@linaro.org> > A: "Paolo Bonzini" <pbonz...@redhat.com> > Cc: qemu-devel@nongnu.org, a...@ozlabs.ru, "jan kiszka" > <jan.kis...@siemens.com>, qemul...@gmail.com, "Avi Kivity" > <avi.kiv...@gmail.com>, stefa...@redhat.com, da...@gibson.dropbear.id.au > Inviato: Martedì, 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 <pbonz...@redhat.com> wrote: > > From: Avi Kivity <avi.kiv...@gmail.com> > > > > 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 (containers > > and aliases) are eliminated by the memory core, leaving only device regions > > which have reasonable sizes. An IOMMU however cannot be eliminated by the > > memory core, and may have an artificial size. > > > +static MemoryRegionSection limit(MemoryRegionSection section) > > +{ > > + unsigned practical_as_bits = MIN(TARGET_PHYS_ADDR_SPACE_BITS, 62); > > + hwaddr as_limit; > > + > > + as_limit = (hwaddr)1 << practical_as_bits; > > + > > + section.size = MIN(section.offset_within_address_space + section.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? Paolo