2010/5/7 Artyom Tarasenko <atar4q...@googlemail.com>: > phys_page_find (exec.c) returns sometimes a page for addresses where > nothing is connected. > > One example, done with qemu-system-sparc -M SS-20 > > ok f13ffff0 2f spacec@ . > > // The address translates correctly, in cpu_physical_memory_rw > // addr== 0xff13ffff0 (where nothing is connected) > // but then phys_page_find returns a nonzero and produces > > Unassigned mem read access of 1 byte to 0000000ff15ffff0 from xxxxx > > (note the "5" in the line above where "3" is expected) > > I wonder if this is only true for non-wired addresses, or whether > phys_page_find can also > find wrong pages for the addresses where something is connected? > > Or is my assumption is wrong and phys_page_find can return a page for > not-connected > addresses and the bug is actually in cpu_physical_memory_rw ? > > Is the qemu algorithm of working with the physical address space > described somewhere?
I'm surprised that no one is interested in discussing this issue. It may affect other targets too. After some debugging I see that page 0xff15ff000 is allocated twice when emulating SS-20. Can this be a problem? >From the phys_page_find logic it looks like the pages are expected to be allocated in the natural order: the loop descends till the page hits a search mask. sun4m_hw_init initializes devices in a more or less random order. Can this be a problem? Also the function cpu_register_physical_memory_offset the following comment: ...Both start_addr and region_offset are rounded down to a page boundary before calculating this offset. This should not be a problem unless the low bits of start_addr and region_offset differ. */ What is meant here by "low bits"? I put a check if((region_offset & TARGET_PAGE_MASK)!=(start_addr & TARGET_PAGE_MASK)) printf... and it gets hit a lot within the address range 0xd00000512-ff1800000 . Does it indicate a problem? -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
