From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Mackerras Date: Thu, 27 Sep 2018 01:45:21 +0000 Subject: Re: [RFC PATCH 20/32] KVM: PPC: Book3S HV: Nested guest entry via hypercall Message-Id: <20180927014521.GB20169@fergus> List-Id: References: <1537524123-9578-21-git-send-email-paulus@ozlabs.org> In-Reply-To: <1537524123-9578-21-git-send-email-paulus@ozlabs.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kvm-ppc@vger.kernel.org On Thu, Sep 27, 2018 at 10:57:17AM +1000, David Gibson wrote: > On Wed, Sep 26, 2018 at 08:59:22PM +1000, Paul Mackerras wrote: > > On Wed, Sep 26, 2018 at 03:41:07PM +1000, David Gibson wrote: > > > On Fri, Sep 21, 2018 at 08:01:51PM +1000, Paul Mackerras wrote: > > > > + if (!kvm_is_radix(vcpu->kvm)) > > > > + return H_FUNCTION; > > > > > > Would it be safer / cleaner to have this instead check that the L1 has > > > completed an H_SET_PARTITION_TABLE? Which wouldn't be allowed for an > > > HPT guest. > > > > There is no valid bit in the PTCR value, and the PTCR could have been > > set via the one-reg interface without there having been a > > H_SET_PARTITION_TABLE in the lifetime of this KVM instance (for > > example when the L1 guest has been migrated in from another machine), > > so I don't see a foolproof way to do what you suggest. > > Ah, right. > > Would checking if the vPTCR is != it's initial value (0?) do the job? > (AFAICT PTCR=0 would be unusable, even if technically allowed). If I did check PTCR, what error code would you suggest? I'm sure you'd tell me not to use H_FUNCTION. :) Paul.