Re: How can I know Page Table address on RAM?

[Junho]

Hello Nick and ppc developers,

I would like to ask you a follow-up question.

I'm currently working on qemu with ppc e5500 target.

For the page table debugging, I checked the mapping of virtual and physical addresses where TLB entry is added.

To be specific, I printed both addr and paddr on tlb_set_page_with_attrs function (https://gitlab.com/qemu-project/qemu/-/blob/master/accel/tcg/cputlb.c?ref_type=heads#L1278).

I expected that the physical addresses mapped to each virtual address would not change except for the initial TLB writing.

After initial writing, I expected, If the TLB flush worked, a physical address should be updated from the invalid data back to the previously recorded address. 

However, the printing result shows that the physical address mapped to a virtual address keeps on changing to different addresses like: 

       paddr: 0x00000000 -> 0x2966b000 -> 0x2166b000 -> 0x2966b000 -> 0x22166b000 -> 0x22d66b000 -> ...

I considered only one mmu index for this printing.

It means that the mapping table is continuously changing, but this behavior does not make sense to me. 

Can you guess any reasons why the physical addresses are changing to different addresses? Is this a normal behavior?

Thank you 

Junho

2024년 1월 23일 (화) 오후 4:36, Nicholas Piggin <npiggin@gmail.com>님이 작성:

On Mon Jan 22, 2024 at 6:54 PM AEST, Thomas Huth wrote:
> On 22/01/2024 05.11, Junho wrote:
> > Hello,
> >
> > I'm a QEMU user with PowerPc target architecture.
> > I have some personal modifications related to tb jmp cache and chaining
> > logic to improve the performance of a specific guest code. To verify the
> > safety, I have to guarantee that the page table on RAM does not change after
> > initialization. Do you have any information related to this work? Currently,
> > what I need to find is the page table start address on the RAM so that I can
> > test with the range detected.
> >
> > I look forward to your response.
> >
> > Thank you
> > Junho
>
>   Hi,
>
> maybe it's best to ask this question on the qemu-ppc mailing list instead
> (done now), since most PPC folks will rather read than one instead of the
> high-traffic qemu-devel mailing list.

Hi Junho,

ppc targets have a lot of different MMUs, so it depends what you are
looking at.

The hash MMU has a page table that is linear in physical (real) memory,
so you might feasibly be able to watch it for updates. The SDR1 SPR has
hash table base and size. ISA v3.0 and later use an in-memory table
that is pointed to by the PTCR SPR.

Other types are software loaded and radix page tables which might be
infeasible or impossible to really track.

It would be interesting to know what kind of modifications you're doing,
it's possible they might be achieved another way. For example, there is
no requirement in the architecture for the TLB to be kept coherent with
page table modifications, so you might be able to watch for TLB flush
instructions rather than page table changes.

Thanks,
Nick