[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: phys_page_find bug?
From: |
Artyom Tarasenko |
Subject: |
[Qemu-devel] Re: phys_page_find bug? |
Date: |
Thu, 20 May 2010 22:00:09 +0200 |
2010/5/7 Artyom Tarasenko <address@hidden>:
> 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/