On Wed, Oct 2, 2013 at 8:33 AM, Jia Liu <pro...@gmail.com> wrote:
> Hi Sebastian,
>
> On Wed, Oct 2, 2013 at 1:12 PM, Sebastian Macke <sebast...@macke.de>
> wrote:
> > Hi,
> >
> > this patch corrects two problems for the OpenRISC Target in QEMU. The
> first
> > one corrects one obvious bug
> > concerning the handling of page faults while reading from a page.
>
> @@ -102,7 +102,7 @@ int cpu_openrisc_get_phys_data(OpenRISCCPU *cpu,
> }
> }
>
> - if ((rw & 0) && ((right & PAGE_READ) == 0)) {
> + if (!(rw & 1) && ((right & PAGE_READ) == 0)) {
> return TLBRET_BADADDR;
> }
> if ((rw & 1) && ((right & PAGE_WRITE) == 0)) {
>
> They are just two type of one code...
>
No, (rw & 0) always evaluates to 0.
>
> > The second
> > part removes a non-conforming behavior for the first page of the memory.
>
> @@ -122,13 +122,6 @@ static int cpu_openrisc_get_phys_addr(OpenRISCCPU
> *cpu,
> {
> int ret = TLBRET_MATCH;
>
> - /* [0x0000--0x2000]: unmapped */
> - if (address < 0x2000 && (cpu->env.sr & SR_SM)) {
> - *physical = address;
> - *prot = PAGE_READ | PAGE_WRITE;
> - return ret;
> - }
> -
>
> May you please explain more about why the first page is non-conforming?
> The Arch manual told me 0x0000--0x2000 is unmapped.
>
It shows an example where *software* leaves 0x0000 - 0x2000 unmapped,
the hardware should still allow for this area to be mapped.
Stefan
