diff mbox

[1/7] target/openrisc: Fixes for memory debugging

Message ID 575d21dff52df4fa53d17e77728018453f82e8e5.1492384862.git.shorne@gmail.com
State New
Headers show

Commit Message

Stafford Horne April 16, 2017, 11:23 p.m. UTC
When debugging in gdb you might want to inspect instructions in mapped
pages or in exception vectors like 0x800 etc.  This was previously not
possible in qemu since the *get_phys_page_debug() routine only looked
into the data tlb.

Change to fall back to look into instruction tlb and plain physical
pages.

Signed-off-by: Stafford Horne <shorne@gmail.com>
---
 target/openrisc/mmu.c | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

Comments

Richard Henderson April 18, 2017, 7:47 a.m. UTC | #1
On 04/16/2017 04:23 PM, Stafford Horne wrote:
> When debugging in gdb you might want to inspect instructions in mapped
> pages or in exception vectors like 0x800 etc.  This was previously not
> possible in qemu since the *get_phys_page_debug() routine only looked
> into the data tlb.
>
> Change to fall back to look into instruction tlb and plain physical
> pages.
>
> Signed-off-by: Stafford Horne <shorne@gmail.com>

Oh the horrors of a software managed TLB.

You might do well to architecturally define an SPR that holds the page table 
base, even if for real hardware that's only used by the software refill to load 
up the address.

That would give qemu the option of performing a real page table walk.  This 
would fix this debug hook properly (so that you can examine pages that aren't 
in the TLB at all).  It would also optionally allow QEMU to skip the software 
refill, which *significantly* speeds up emulation.

That said,

Reviewed-by: Richard Henderson <rth@twiddle.net>


r~
Stafford Horne April 18, 2017, 2:18 p.m. UTC | #2
On Tue, Apr 18, 2017 at 12:47:30AM -0700, Richard Henderson wrote:
> On 04/16/2017 04:23 PM, Stafford Horne wrote:
> > When debugging in gdb you might want to inspect instructions in mapped
> > pages or in exception vectors like 0x800 etc.  This was previously not
> > possible in qemu since the *get_phys_page_debug() routine only looked
> > into the data tlb.
> > 
> > Change to fall back to look into instruction tlb and plain physical
> > pages.
> > 
> > Signed-off-by: Stafford Horne <shorne@gmail.com>
> 
> Oh the horrors of a software managed TLB.
> 
> You might do well to architecturally define an SPR that holds the page table
> base, even if for real hardware that's only used by the software refill to
> load up the address.
> 
> That would give qemu the option of performing a real page table walk.  This
> would fix this debug hook properly (so that you can examine pages that
> aren't in the TLB at all).  It would also optionally allow QEMU to skip the
> software refill, which *significantly* speeds up emulation.

Understood, I guess we would also need a way to represent which paging
model we are using (1 level, 2 level etc)?

> That said,
> 
> Reviewed-by: Richard Henderson <rth@twiddle.net>

Thanks for the review.

-Stafford

> 
> r~
Richard Henderson April 18, 2017, 3 p.m. UTC | #3
On 04/18/2017 07:18 AM, Stafford Horne wrote:
> On Tue, Apr 18, 2017 at 12:47:30AM -0700, Richard Henderson wrote:
>> On 04/16/2017 04:23 PM, Stafford Horne wrote:
>>> When debugging in gdb you might want to inspect instructions in mapped
>>> pages or in exception vectors like 0x800 etc.  This was previously not
>>> possible in qemu since the *get_phys_page_debug() routine only looked
>>> into the data tlb.
>>>
>>> Change to fall back to look into instruction tlb and plain physical
>>> pages.
>>>
>>> Signed-off-by: Stafford Horne <shorne@gmail.com>
>>
>> Oh the horrors of a software managed TLB.
>>
>> You might do well to architecturally define an SPR that holds the page table
>> base, even if for real hardware that's only used by the software refill to
>> load up the address.
>>
>> That would give qemu the option of performing a real page table walk.  This
>> would fix this debug hook properly (so that you can examine pages that
>> aren't in the TLB at all).  It would also optionally allow QEMU to skip the
>> software refill, which *significantly* speeds up emulation.
>
> Understood, I guess we would also need a way to represent which paging
> model we are using (1 level, 2 level etc)?

I suppose.  You really have a 1-level lookup?  For huge pages only, or is this 
a virtual 2-level lookup with double-faulting to handle the second level?


r~
Stafford Horne April 19, 2017, 8:06 p.m. UTC | #4
On Tue, Apr 18, 2017 at 08:00:06AM -0700, Richard Henderson wrote:
> On 04/18/2017 07:18 AM, Stafford Horne wrote:
> > On Tue, Apr 18, 2017 at 12:47:30AM -0700, Richard Henderson wrote:
> > > On 04/16/2017 04:23 PM, Stafford Horne wrote:
> > > > When debugging in gdb you might want to inspect instructions in mapped
> > > > pages or in exception vectors like 0x800 etc.  This was previously not
> > > > possible in qemu since the *get_phys_page_debug() routine only looked
> > > > into the data tlb.
> > > > 
> > > > Change to fall back to look into instruction tlb and plain physical
> > > > pages.
> > > > 
> > > > Signed-off-by: Stafford Horne <shorne@gmail.com>
> > > 
> > > Oh the horrors of a software managed TLB.
> > > 
> > > You might do well to architecturally define an SPR that holds the page table
> > > base, even if for real hardware that's only used by the software refill to
> > > load up the address.
> > > 
> > > That would give qemu the option of performing a real page table walk.  This
> > > would fix this debug hook properly (so that you can examine pages that
> > > aren't in the TLB at all).  It would also optionally allow QEMU to skip the
> > > software refill, which *significantly* speeds up emulation.
> > 
> > Understood, I guess we would also need a way to represent which paging
> > model we are using (1 level, 2 level etc)?
> 
> I suppose.  You really have a 1-level lookup?  For huge pages only, or is
> this a virtual 2-level lookup with double-faulting to handle the second
> level?

We don't,  the linux kernel is implemented with basic 2-level lookup's with
single fault.  I was just thinking its not ideal for the emulator to assume
the paging model since it could change from kernel to kernel.

But I guess it will not change anytime soon.

-Stafford
diff mbox

Patch

diff --git a/target/openrisc/mmu.c b/target/openrisc/mmu.c
index 56b11d3..a6d7bcd 100644
--- a/target/openrisc/mmu.c
+++ b/target/openrisc/mmu.c
@@ -124,7 +124,7 @@  static int cpu_openrisc_get_phys_addr(OpenRISCCPU *cpu,
 {
     int ret = TLBRET_MATCH;
 
-    if (rw == 2) {    /* ITLB */
+    if (rw == MMU_INST_FETCH) {    /* ITLB */
        *physical = 0;
         ret = cpu->env.tlb->cpu_openrisc_map_address_code(cpu, physical,
                                                           prot, address, rw);
@@ -221,12 +221,27 @@  hwaddr openrisc_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
     OpenRISCCPU *cpu = OPENRISC_CPU(cs);
     hwaddr phys_addr;
     int prot;
+    int miss;
 
-    if (cpu_openrisc_get_phys_addr(cpu, &phys_addr, &prot, addr, 0)) {
-        return -1;
+    /* Check memory for any kind of address, since during debug the
+       gdb can ask for anything, check data tlb for address */
+    miss = cpu_openrisc_get_phys_addr(cpu, &phys_addr, &prot, addr, 0);
+
+    /* Check instruction tlb */
+    if (miss) {
+        miss = cpu_openrisc_get_phys_addr(cpu, &phys_addr, &prot, addr, MMU_INST_FETCH);
+    }
+
+    /* Last, fall back to a plain address */
+    if (miss) {
+        miss = cpu_openrisc_get_phys_nommu(cpu, &phys_addr, &prot, addr, 0);
     }
 
-    return phys_addr;
+    if (miss) {
+        return -1;
+    } else {
+        return phys_addr;
+    }
 }
 
 void cpu_openrisc_mmu_init(OpenRISCCPU *cpu)