----- 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

Reply via email to