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

[Jia Liu]

On Wed, Oct 2, 2013 at 2:15 PM, Stefan Kristiansson
<address@hidden> wrote:
> 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.

OK, thank you. I will send a PULL Request soon.

Reviewed-by: Jia Liu <address@hidden>

>
> Stefan

Regards,
Jia