> > > 3: > > > /* Emulate H_SET_DABR/X on P8 for the sake of compat mode > > > guests */ > > > rlwimi r5, r4, 5, DAWRX_DR | DAWRX_DW > > > c00000000010b03c: 74 2e 85 50 rlwimi r5,r4,5,25,26 > > > rlwimi r5, r4, 2, DAWRX_WT > > > c00000000010b040: f6 16 85 50 rlwimi r5,r4,2,27,27 > > > clrrdi r4, r4, 3 > > > c00000000010b044: 24 07 84 78 rldicr r4,r4,0,60 > > > std r4, VCPU_DAWR(r3) > > > c00000000010b048: c0 13 83 f8 std r4,5056(r3) > > > std r5, VCPU_DAWRX(r3) > > > c00000000010b04c: c8 13 a3 f8 std r5,5064(r3) > > > mtspr SPRN_DAWR, r4 > > > c00000000010b050: a6 2b 94 7c mtspr 180,r4 > > > mtspr SPRN_DAWRX, r5 > > > c00000000010b054: a6 2b bc 7c mtspr 188,r5 > > > li r3, 0 > > > c00000000010b058: 00 00 60 38 li r3,0 > > > blr > > > c00000000010b05c: 20 00 80 4e blr > > > > It's the `mtspr SPRN_DAWR, r4` as you're HV=0. I'm not sure how > > nested works > > in that regard. Is the level above suppose to trap and emulate > > that? > > > > Yeah so as a nested hypervisor we need to avoid that call to mtspr > SPRN_DAWR since it's HV privileged and we run with HV = 0. > > The fix will be to check kvmhv_on_pseries() before doing the write. In > fact we should avoid the write any time we call the function from _not_ > real mode. > > I'll submit a fix for the KVM side. Doesn't look like this is anything > to do with Mikey's patch, was always broken as far as I can tell. Thanks Suraj. Mikey
