qemu-devel
[Top][All Lists]
Advanced

[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/



reply via email to

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