On 18 August 2014 01:14, Peter Crosthwaite <peter.crosthwa...@xilinx.com> wrote: > On Mon, Aug 18, 2014 at 8:23 AM, Peter Maydell <peter.mayd...@linaro.org> > wrote: >> On 15 August 2014 08:17, Peter Crosthwaite <peter.crosthwa...@xilinx.com> >> wrote: >>> If we were to repair this, a simpler and more effective check would be >>> to only assert collisions between same-priority regions. The fact that >>> colliding memory regions may-overlap is then left as implicit by the >>> fact that they have different priorities. >> >> I'm not sure your suggestion here would work, because priorities >> are only significant relative to other regions within the same >> container, whereas collisions can occur between two regions >> which don't have the same parent container and whose priorities are >> therefore not comparable. (For instance, consider [ A [ B C ] ] >> where A and B end up overlapping.)
> But that is not a problem that is solved by the old may_overlap flag > is it? The check deleted here is not hierarchy aware so we have never > been able to detect that case. I think we should take a "clean slate" > approach on the implementation of the collision detection. Big change > is needed to get the check in the right place in code, whether it's > same-priority based or using may_overlap. Oops, I mistakenly thought this check was happening at the flattened-ranges point, but it's done when a subregion is added to a container. Maybe you're right that we should be able to allow overlaps if the priorities are different and not otherwise, then. But I'd rather we actually did that rather than just removing the check completely. thanks -- PMM
