Re: [RFC PATCH v0 2/2] KVM: PPC: Book3S HV: Use H_RPT_INVALIDATE in nested KVM
From: Paul Mackerras <hidden>
Date: 2020-07-09 10:10:05
On Thu, Jul 09, 2020 at 02:38:51PM +0530, Bharata B Rao wrote:
On Thu, Jul 09, 2020 at 03:18:03PM +1000, Paul Mackerras wrote:quoted
On Fri, Jul 03, 2020 at 04:14:20PM +0530, Bharata B Rao wrote:quoted
In the nested KVM case, replace H_TLB_INVALIDATE by the new hcall H_RPT_INVALIDATE if available. The availability of this hcall is determined from "hcall-rpt-invalidate" string in ibm,hypertas-functions DT property.What are we going to use when nested KVM supports HPT guests at L2? L1 will need to do partition-scoped tlbies with R=0 via a hypercall, but H_RPT_INVALIDATE says in its name that it only handles radix page tables (i.e. R=1).For L2 HPT guests, the old hcall is expected to work after it adds support for R=0 case?
That was the plan.
The new hcall should be advertised via ibm,hypertas-functions only for radix guests I suppose.
Well, the L1 hypervisor is a radix guest of L0, so it would have H_RPT_INVALIDATE available to it? I guess the question is whether H_RPT_INVALIDATE is supposed to do everything, that is, radix process-scoped invalidations, radix partition-scoped invalidations, and HPT partition-scoped invalidations. If that is the plan then we should call it something different. This patchset seems to imply that H_RPT_INVALIDATE is at least going to be used for radix partition-scoped invalidations as well as radix process-scoped invalidations. If you are thinking that in future when we need HPT partition-scoped invalidations for a radix L1 hypervisor running a HPT L2 guest, we are going to define a new hypercall for that, I suppose that is OK, though it doesn't really seem necessary. Paul.