[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH] target/ppc: fix address translation bug for hash table m
From: |
Bruno Piazera Larsen |
Subject: |
Re: [RFC PATCH] target/ppc: fix address translation bug for hash table mmus |
Date: |
Tue, 8 Jun 2021 11:39:24 -0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 |
On 07/06/2021 18:06, Richard Henderson
wrote:
On
6/7/21 12:29 PM, Bruno Piazera Larsen wrote:
I just tried sending mmu_idx all the way
down, but I ran into a very weird bug of gcc. If we have to add
one more parameter that GCC can't just optimize away we get at
least a slow down of 5x for the first test of check-acceptance
(could be more, but the test times out after 900 seconds, so I'm
not sure).
That's odd. We already have more arguments than the number of
argument registers... A 5x slowdown is distinctly odd.
I did some more digging and the problem is not with
ppc_radix64_check_prot, the problem is ppc_radix64_xlate, which
currently has 7 arguments and we're increasing to 8. 7 feels like
the correct number, but I couldn't find docs supporting it, so I
could be wrong.
One way that I managed to get around that
is saving the current MSR, setting it to 5, and restoring after
the xlate call. The code ended up something like:
int new_idx = (5<<HFLAGS_IMMU_IDX) |
(5<<HFLAGS_DMMU_IDX);
int clr = (7<<HFLAGS_IMMU_IDX) |
(7<<HFLAGS_DMMU_IDX);
int old_idx = env->msr & clr;
clr = ~clr;
/* set new msr so we don't need to send the mmu_idx */
env->msr = (env->msr & clr) | new_idx;
ret = ppc_radix64_partition_scoped_xlate(...);
/* restore old mmu_idx */
env->msr = (env->msr & clr) | old_idx;
No, this is silly.
We need to do one of two things:
- make sure everything is inlined,
- reduce the number of arguments.
We're currently passing in 9 arguments, which really is too many
already. We should be using something akin to mmu_ctx_t, but
probably specific to radix64 without the random stuff collected
for random other mmu models.
That means we'd have to define radix_ctx_t (or however we call
it) in radix64.h, setup the struct on ppc_xlate, then pass it to
ppc_radix64_xlate.
From looking at the code, it seems the most useful bits to put in
the struct are: eaddr, g_addr, h_addr, {h,g}_prot,
{g,h}_page_size, mmu_idx and guest_visible. They all seem
reasonable to me, but I might be missing something again.
r~
Another question: I know hash mmus don't have this problem, but
since ppc_jumbo_xlate also uses mmu_idx, should we make those xlate
user mmu_idxs as well? I tested and it doesn't make a time
difference.
- [RFC PATCH] target/ppc: fix address translation bug for hash table mmus, Bruno Larsen (billionai), 2021/06/02
- Re: [RFC PATCH] target/ppc: fix address translation bug for hash table mmus, Richard Henderson, 2021/06/02
- Re: [RFC PATCH] target/ppc: fix address translation bug for hash table mmus, Bruno Piazera Larsen, 2021/06/02
- Re: [RFC PATCH] target/ppc: fix address translation bug for hash table mmus, Richard Henderson, 2021/06/02
- Re: [RFC PATCH] target/ppc: fix address translation bug for hash table mmus, Bruno Piazera Larsen, 2021/06/07
- Re: [RFC PATCH] target/ppc: fix address translation bug for hash table mmus, Richard Henderson, 2021/06/07
- Re: [RFC PATCH] target/ppc: fix address translation bug for hash table mmus,
Bruno Piazera Larsen <=
- Re: [RFC PATCH] target/ppc: fix address translation bug for hash table mmus, Richard Henderson, 2021/06/08
- Re: [RFC PATCH] target/ppc: fix address translation bug for hash table mmus, Bruno Piazera Larsen, 2021/06/08
- Re: [RFC PATCH] target/ppc: fix address translation bug for hash table mmus, Bruno Piazera Larsen, 2021/06/08