linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: Nicholas Piggin <npiggin@gmail.com>,
	Bharata B Rao <bharata@linux.ibm.com>,
	kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Cc: david@gibson.dropbear.id.au, farosas@linux.ibm.com
Subject: Re: [PATCH v7 4/6] KVM: PPC: Book3S HV: Nested support in H_RPT_INVALIDATE
Date: Fri, 07 May 2021 16:00:08 +0530	[thread overview]
Message-ID: <87wnsa6dlb.fsf@linux.ibm.com> (raw)
In-Reply-To: <1620280840.cytifux60q.astroid@bobo.none>

Nicholas Piggin <npiggin@gmail.com> writes:


...

> + */
>> +long do_h_rpt_invalidate_pat(struct kvm_vcpu *vcpu, unsigned long lpid,
>> +			     unsigned long type, unsigned long pg_sizes,
>> +			     unsigned long start, unsigned long end)
>> +{
>> +	struct kvm_nested_guest *gp;
>> +	long ret;
>> +	unsigned long psize, ap;
>> +
>> +	/*
>> +	 * If L2 lpid isn't valid, we need to return H_PARAMETER.
>> +	 *
>> +	 * However, nested KVM issues a L2 lpid flush call when creating
>> +	 * partition table entries for L2. This happens even before the
>> +	 * corresponding shadow lpid is created in HV which happens in
>> +	 * H_ENTER_NESTED call. Since we can't differentiate this case from
>> +	 * the invalid case, we ignore such flush requests and return success.
>> +	 */
>> +	gp = kvmhv_find_nested(vcpu->kvm, lpid);
>> +	if (!gp)
>> +		return H_SUCCESS;
>> +
>> +	/*
>> +	 * A flush all request can be handled by a full lpid flush only.
>> +	 */
>> +	if ((type & H_RPTI_TYPE_NESTED_ALL) == H_RPTI_TYPE_NESTED_ALL)
>> +		return do_tlb_invalidate_nested_all(vcpu, lpid, RIC_FLUSH_ALL);
>> +
>> +#if 0
>> +	/*
>> +	 * We don't need to handle a PWC flush like process table here,
>> +	 * because intermediate partition scoped table in nested guest doesn't
>> +	 * really have PWC. Only level we have PWC is in L0 and for nested
>> +	 * invalidate at L0 we always do kvm_flush_lpid() which does
>> +	 * radix__flush_all_lpid(). For range invalidate at any level, we
>> +	 * are not removing the higher level page tables and hence there is
>> +	 * no PWC invalidate needed.
>> +	 */
>> +	if (type & H_RPTI_TYPE_PWC) {
>> +		ret = do_tlb_invalidate_nested_all(vcpu, lpid, RIC_FLUSH_PWC);
>> +		if (ret)
>> +			return H_P4;
>> +	}
>> +#endif
>
> I think removing this #if 0 and the unnecessary code is fine, just a bit 
> more explanation in the comment would help. And "doesn't really" implies
> it sort of might a little bit, I think what you want is "really doesn't" 
> :)

yes.

>
> As I understand it, the L0 does not cache any intermediate levels of the
> nested guest's partition scope at all. Only the nested HV's pte entries
> are copied into the shadow page table, so we only care if the PTEs are
> changed, and the PWCs that the processor creates for the shadow page
> table are managed by the kvmppc_unmap_pte() etc functions... I think?

That is correct. The reason I added the comment there was to clarify why
the PWC type is not handled in case of partition scoped invalidate
similar to process scoped invalidate. The code fragment was left as an
indication of what should happen theoretically.

All higher levels of guest (L1, L2.. etc) have partition tables that are
not really used for hardware page table walk. H_RPT_INVALIDATE hcall is used as
a hint to free those page table entries. L0 on receiving the hcall will
forward the same to higher levels guest which after invalidating its
shadow pte will further issue the H_RPT_INVALIDATE hcall to clear
parition scoped entries of the current guest.

If it is a range TLB flush, we just clear the shadow pte, higher levels
page tables are not modified and hence no PWC flush is required.

If it is full lpid flush because of RIC=1/2 or because range is 0 -> -1
we do free the full partition table and does a kvmhv_flush_lpid()
which will eventually ends up calling radix__flush_all_lpid(). 

These function names are kept in the comment so that a new person
looking at the code can easily follow the code path. 


-aneesh

  reply	other threads:[~2021-05-07 10:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-05 15:46 [PATCH v7 0/6] Support for H_RPT_INVALIDATE in PowerPC KVM Bharata B Rao
2021-05-05 15:46 ` [PATCH v7 1/6] KVM: PPC: Book3S HV: Fix comments of H_RPT_INVALIDATE arguments Bharata B Rao
2021-05-05 15:46 ` [PATCH v7 2/6] powerpc/book3s64/radix: Add H_RPT_INVALIDATE pgsize encodings to mmu_psize_def Bharata B Rao
2021-05-05 15:46 ` [PATCH v7 3/6] KVM: PPC: Book3S HV: Add support for H_RPT_INVALIDATE Bharata B Rao
2021-05-06  5:45   ` Nicholas Piggin
2021-05-06  6:31     ` Bharata B Rao
2021-05-05 15:46 ` [PATCH v7 4/6] KVM: PPC: Book3S HV: Nested support in H_RPT_INVALIDATE Bharata B Rao
2021-05-06  6:15   ` Nicholas Piggin
2021-05-07 10:30     ` Aneesh Kumar K.V [this message]
2021-05-05 15:46 ` [PATCH v7 5/6] KVM: PPC: Book3S HV: Add KVM_CAP_PPC_RPT_INVALIDATE capability Bharata B Rao
2021-05-05 15:46 ` [PATCH v7 6/6] KVM: PPC: Book3S HV: Use H_RPT_INVALIDATE in nested KVM Bharata B Rao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wnsa6dlb.fsf@linux.ibm.com \
    --to=aneesh.kumar@linux.ibm.com \
    --cc=bharata@linux.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=farosas@linux.ibm.com \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=npiggin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).