On Thu, 10 Feb 2022 at 11:48, Philippe Mathieu-Daudé <[email protected]> wrote: > > Hi Alex, > > On 10/2/22 12:30, Alex Bennée wrote: > > The previous numbers were a guess at best and rather arbitrary without > > taking into account anything that might be loaded. Instead of using > > guesses based on the state of registers implement a new function that: > > > > a) scans the MemoryRegions for the largest RAM block > > b) iterates through all "ROM" blobs looking for the biggest gap > > > > The "ROM" blobs include all code loaded via -kernel and the various > > -device loader techniques. > > > > Signed-off-by: Alex Bennée <[email protected]> > > Cc: Andrew Strauss <[email protected]> > > Cc: Keith Packard <[email protected]> > > Message-Id: <[email protected]> > > > +static LayoutInfo common_semi_find_bases(CPUState *cs) > > { > > - MemoryRegion *subregion; > > + FlatView *fv; > > + LayoutInfo info = { 0, 0, 0, 0 }; > > + > > + RCU_READ_LOCK_GUARD(); > > + > > + fv = address_space_to_flatview(cs->as); > > Why are we using the CPU view and not address_space_memory?
If you have a choice between "use the right view of an address space" and "use the global address_space_memory", it's better to prefer the former, I think. We use the latter in lots of places, but it's not conceptually the right way to think about how the memory system works IMHO. -- PMM
