From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Mackerras Subject: Re: [PATCH 14/23] KVM: PPC: Book3S PR: Delay disabling relocation-on interrupts Date: Sat, 31 Aug 2013 08:55:07 +1000 Message-ID: <20130830225507.GA22538@iris.ozlabs.ibm.com> References: <20130806041259.GF19254@iris.ozlabs.ibm.com> <20130806042337.GT19254@iris.ozlabs.ibm.com> <52C9AA8E-87DE-4746-94B3-A6CC386EA0D9@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Benjamin Herrenschmidt , kvm-ppc@vger.kernel.org, kvm@vger.kernel.org To: Alexander Graf Return-path: Received: from ozlabs.org ([203.10.76.45]:52765 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753535Ab3H3WzN (ORCPT ); Fri, 30 Aug 2013 18:55:13 -0400 Content-Disposition: inline In-Reply-To: <52C9AA8E-87DE-4746-94B3-A6CC386EA0D9@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: 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 > To: Alexander Graf , Benjamin Herrenschmidt > Cc: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org > 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.