On Wed, May 19, 2021 at 05:47:05PM -0500, Richard Henderson wrote:
On 5/19/21 3:37 PM, Richard Henderson wrote:
On 5/18/21 9:52 PM, David Gibson wrote:
I've applied 1..15, still looking at the rest.
Please dequeue. I want to create a new mmu-internal.h, which affects
all the patches from #1.
Alternately, don't. I can move the function later, and it may be a while
before I can get back to this.
Ok, I'll leave them in, since they're good cleanups even without the
rest of the series.
Two outstanding bugs:
(1) mmu-radix64.c vs hypervisors. You'll not see these unless you run kvm
inside of tcg.
Basically, all usage of msr_{hv,pr,ir,dr} within ppc_*_xlate is incorrect.
We should be pulling these from the 3 bits of mmu_idx, as outlined in the
table in hreg_compute_hflags_value.
Ah, that's probably my fault. I reworked those substantially from the
original code (closer to mmu_helper.c). I guess I didn't (and I
suspect I still don't) really understand how the softmmu works.
When you start propagating that around, you see that the second-level
translation for loading the pte (2 of the 3 calls to
ppc_radix64_partition_scoped_xlate) should not be using the mmu_idx related
to the user-mode guest access, but should be using the mmu_idx of the
kernel/hypervisor that owns the page table.
I can't see that mmu-radix64.c has the same problem. I'm not really sure
how the second-level translation for hypervisors works there. Is it by the
hypervisor altering the hash table as it is loaded?
Uh.. you started by saying mmu-radix64.c then talked about the hash
table, so I'm not sure which model you're talking about.