qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [OpenRISC] [PATCH] Correction of the TLB handling of th


From: Stefan Kristiansson
Subject: Re: [Qemu-devel] [OpenRISC] [PATCH] Correction of the TLB handling of the OpenRISC target
Date: Wed, 2 Oct 2013 09:15:28 +0300

On Wed, Oct 2, 2013 at 8:33 AM, Jia Liu <address@hidden> wrote:
Hi Sebastian,

On Wed, Oct 2, 2013 at 1:12 PM, Sebastian Macke <address@hidden> 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

reply via email to

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