qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 08/40] memory: limit sections in the radix tree


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 08/40] memory: limit sections in the radix tree to the actual address space size
Date: Tue, 7 May 2013 13:24:26 -0400 (EDT)


----- Messaggio originale -----
> Da: "Peter Maydell" <address@hidden>
> A: "Paolo Bonzini" <address@hidden>
> Cc: address@hidden, address@hidden, "jan kiszka" <address@hidden>, 
> address@hidden, "Avi Kivity"
> <address@hidden>, address@hidden, address@hidden
> 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 <address@hidden> wrote:
> > From: Avi Kivity <address@hidden>
> >
> > 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

[Prev in Thread] Current Thread [Next in Thread]