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.
> > + 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.
Paul.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
