qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] Power9 VRMA emulation


From: Amol Surati
Subject: Re: [Qemu-ppc] Power9 VRMA emulation
Date: Sat, 18 May 2019 10:47:22 +0530

Hello again,


A bit of testing was carried out.



As it is now, qemu raises a HISI without consulting the VRMA SLB and the
partitions page table.

This is the message it prints for when a (non-zero LPIDR) partition was made
to run under VRMA (for an arbitrary instruction address 0x8ee8):

"Raise exception at 0000000000008ee8 => 00000046 (8000000)"
The error code 8000000 is SRR1_PROTFAULT.



After allowing LPCR_VPM0 as a valid bit for POWERPC_MMU_3_00, and setting
it to 1, the above test was repeated. This is the output:

htab_base 0000000000000000 htab_mask 00000000000007ff hash 0003fffffffffff7
0 htab=0000000000000000/00000000000007ff vsid=0000000001ffffff
ptem=4001ffffff000001 hash=0003fffffffffff7
1 htab=0000000000000000/00000000000007ff vsid=0000000001ffffff
api=4001ffffff000003 hash=fffc000000000008
Raise exception at 0000000000008ee8 => 00000046 (40000000)

The error code 40000000 is SRR1_NOPTE. That code and qemu's attempt to
search in the page table for the partition, correspond with the comment
in the ISA that HISI is to be raised only when (1) VPM is ON and (2)
conditions exist which warrant raising a ISI/DSI.

IIURC, the conditions which warrant raising a storage interrupt are those
which correspond to failure in translating VA to RA (i.e. failure in
finding a valid PTE, assuming TLB was empty).




QEMU seems to ignore that bit of ISA and raises the HISI (in the above
test) without checking the page table. Instead of removing LPCR_VPM0 bit
for POWERPC_MMU_3_00, qemu should consider that bit as 1 for all
purposes except for the display purpose.

Does that make sense, or am I misinterpreting the ISA?

Thank you,
Amol



On Fri, May 17, 2019 at 09:56:57AM +0530, Amol Surati wrote:
> Hello,
> 
> IIUC, with ISA3.0b, VPM0 is considered to be functionally always 1,
> even though its value in the LPCR register may remain/be fixed at 0,
> as it does by default.
> 
> Does this not warrant a change in functions ppc_hash64_handle_mmu_fault,
> ppc_hash64_update_vrma, and others?
> 
> For instance, under the conditions described in ISA3.0b section 5.7.3.3,
> ppc_hash64_handle_mmu_fault raises a HISI without querying the
> VRMA SLB because it finds VPM0 as 0 and so skips that query altogether.
> 
> *799             if (env->spr[SPR_LPCR] & LPCR_VPM0) {
>  800                 slb = &env->vrma_slb;
>  ...
>  808             } else if (raddr < env->rmls) {
>  ...
>  811             } else {
>  812                 /* The access failed, generate the approriate interrupt 
> */
>  813                 if (rwx == 2) {
> *814                     ppc_hash64_set_isi(cs, SRR1_PROTFAULT);
>  ...
>  823             }
> 
> Am I misunderstanding the ISA?
> 
> Thank you,
> Amol



reply via email to

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