On 31.08.2013, at 00:55, Paul Mackerras wrote: > On Fri, Aug 30, 2013 at 06:30:50PM +0200, Alexander Graf wrote: >> >> On 06.08.2013, at 06:23, Paul Mackerras wrote: >> >>> When we are running a PR KVM guest on POWER8, we have to disable the >>> new POWER8 feature of taking interrupts with relocation on, that is, >>> of taking interrupts without disabling the MMU, because the SLB does >>> not contain the normal kernel SLB entries while in the guest. >>> Currently we disable relocation-on interrupts when a PR guest is >>> created, and leave it disabled until there are no more PR guests in >>> existence. >>> >>> This defers the disabling of relocation-on interrupts until the first >> >> It would've been nice to see the original patch on kvm-ppc@vger. > > Here are the headers from my copy of the original mail: > >> Date: Tue, 6 Aug 2013 14:23:37 +1000 >> From: Paul Mackerras <paulus@xxxxxxxxx> >> To: Alexander Graf <agraf@xxxxxxx>, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> >> Cc: kvm-ppc@xxxxxxxxxxxxxxx, kvm@xxxxxxxxxxxxxxx >> Subject: [PATCH 14/23] KVM: PPC: Book3S PR: Delay disabling relocation-on interrupts > > So as far as I can see, I *did* cc it to kvm-ppc@vger. Oh, sorry to not be more explicit here. I meant the one that actually introduced the relocation-on handling: https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-December/102355.html I can't find any trace of that in my inbox, even though it clearly touches KVM PPC code. > >>> + if (!kvm->arch.relon_disabled) { >>> + if (firmware_has_feature(FW_FEATURE_SET_MODE)) { >> >> Is this the same as the endianness setting rtas call? If so, would a PR guest in an HV guest that provides only endianness setting but no relocation-on setting confuse any of this code? > > It is the same hcall, but since the interrupts-with-relocation-on > function was defined in the first PAPR version that has H_SET_MODE, > we shouldn't ever hit that situation. In any case, if we did happen > to run under a (non PAPR-compliant) hypervisor that implemented > H_SET_MODE but not the relocation-on setting, then we couldn't have > enabled relocation-on interrupts in the first place, so it wouldn't > matter. Well, I think Anton's patches do exactly that: https://lists.nongnu.org/archive/html/qemu-ppc/2013-08/msg00253.html I really just want to double-check that we're not shooting ourselves in the foot here. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
