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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
