On Sat, Aug 31, 2013 at 01:13:07AM +0200, Alexander Graf wrote: > > 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. True, Ian should have cc'd it to kvm-ppc@vger, I'll mention it to him. > > > > >>> + 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. I still think there's no real problem, since there would be no other way to enable relocation-on interrupts other than H_SET_MODE. So if H_SET_MODE can't control that setting, then it must be disabled already. However, we should also make sure that H_SET_MODE supports changing the relocation-on setting when it first goes in. I'm going to want that soon anyway since I'm working on POWER8 KVM support at the moment. Paul. -- 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
