All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, oliver.upton@linux.dev,
	darren@os.amperecomputing.com,
	d.scott.phillips@amperecomputing.com
Subject: Re: [RFC PATCH] kvm: nv: Optimize the unmapping of shadow S2-MMU tables.
Date: Wed, 06 Mar 2024 10:23:03 +0000	[thread overview]
Message-ID: <877cifr75k.wl-maz@kernel.org> (raw)
In-Reply-To: <2911d04d-a785-4d60-9a8d-be0d2cec21de@os.amperecomputing.com>

On Tue, 05 Mar 2024 18:33:27 +0000,
Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com> wrote:
> 
> >>>> index 61bdd8798f83..3948681426a0 100644
> >>>> --- a/arch/arm64/kvm/mmu.c
> >>>> +++ b/arch/arm64/kvm/mmu.c
> >>>> @@ -1695,6 +1695,13 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >>>>    					     memcache,
> >>>>    					     KVM_PGTABLE_WALK_HANDLE_FAULT |
> >>>>    					     KVM_PGTABLE_WALK_SHARED);
> >>>> +		if ((nested || kvm_is_l1_using_shadow_s2(vcpu)) && !ret) {
> >>> 
> >>> I don't understand this condition. If nested is non-NULL, it's because
> >>> we're using a shadow S2. So why the additional condition?
> >> 
> >> No, nested is set only for L2, for L1 it is not.
> >> To handle L1 shadow S2 case, I have added this condition.
> > 
> > But there is *no shadow* for L1 at all. The only way to get a shadow
> > is to be outside of the EL2(&0) translation regime. El2(&0) itself is
> > always backed by the canonical S2. By definition, L1 does not run with
> > a S2 it is in control of. No S2, no shadow.
> 
> Shadow, I mean nested_mmus[0] which is used(first consumer of the
> S2-MMU array) while L1 booting till it switches to NV2.

Please fix your terminology:

- if someone is using *any* of the nested_mmus[], then it is an L2. It
  may come from the same guest binary, but it doesn't change that it
  has changed translation regime to EL1&0. So by definition, it is an
  L2. Yes, booting a Linux guest at EL2 involve both an L1 (the EL2
  part) *and* an L2 (the EL1 part).

- I don't understand 'till it switches to NV2'. Do you mean EL2?

> As per my tracing, the nested_mmus[0] is used for L1 after first ERET
> trap while L1 is booting and switches back to canonical S2, when it is
> moved to NV2.
> 
> In this window, if the pages are unmapped, we need to unmap from the
> nested_mmus[0] table.

Well, we need to unmap things from all shadow PTs that target the same
PA. Index 0 isn't special.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, oliver.upton@linux.dev,
	darren@os.amperecomputing.com,
	d.scott.phillips@amperecomputing.com
Subject: Re: [RFC PATCH] kvm: nv: Optimize the unmapping of shadow S2-MMU tables.
Date: Wed, 06 Mar 2024 10:23:03 +0000	[thread overview]
Message-ID: <877cifr75k.wl-maz@kernel.org> (raw)
In-Reply-To: <2911d04d-a785-4d60-9a8d-be0d2cec21de@os.amperecomputing.com>

On Tue, 05 Mar 2024 18:33:27 +0000,
Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com> wrote:
> 
> >>>> index 61bdd8798f83..3948681426a0 100644
> >>>> --- a/arch/arm64/kvm/mmu.c
> >>>> +++ b/arch/arm64/kvm/mmu.c
> >>>> @@ -1695,6 +1695,13 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >>>>    					     memcache,
> >>>>    					     KVM_PGTABLE_WALK_HANDLE_FAULT |
> >>>>    					     KVM_PGTABLE_WALK_SHARED);
> >>>> +		if ((nested || kvm_is_l1_using_shadow_s2(vcpu)) && !ret) {
> >>> 
> >>> I don't understand this condition. If nested is non-NULL, it's because
> >>> we're using a shadow S2. So why the additional condition?
> >> 
> >> No, nested is set only for L2, for L1 it is not.
> >> To handle L1 shadow S2 case, I have added this condition.
> > 
> > But there is *no shadow* for L1 at all. The only way to get a shadow
> > is to be outside of the EL2(&0) translation regime. El2(&0) itself is
> > always backed by the canonical S2. By definition, L1 does not run with
> > a S2 it is in control of. No S2, no shadow.
> 
> Shadow, I mean nested_mmus[0] which is used(first consumer of the
> S2-MMU array) while L1 booting till it switches to NV2.

Please fix your terminology:

- if someone is using *any* of the nested_mmus[], then it is an L2. It
  may come from the same guest binary, but it doesn't change that it
  has changed translation regime to EL1&0. So by definition, it is an
  L2. Yes, booting a Linux guest at EL2 involve both an L1 (the EL2
  part) *and* an L2 (the EL1 part).

- I don't understand 'till it switches to NV2'. Do you mean EL2?

> As per my tracing, the nested_mmus[0] is used for L1 after first ERET
> trap while L1 is booting and switches back to canonical S2, when it is
> moved to NV2.
> 
> In this window, if the pages are unmapped, we need to unmap from the
> nested_mmus[0] table.

Well, we need to unmap things from all shadow PTs that target the same
PA. Index 0 isn't special.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-03-06 10:23 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-05  5:46 [RFC PATCH] kvm: nv: Optimize the unmapping of shadow S2-MMU tables Ganapatrao Kulkarni
2024-03-05  5:46 ` Ganapatrao Kulkarni
2024-03-05  8:46 ` Oliver Upton
2024-03-05  8:46   ` Oliver Upton
2024-03-06  5:31   ` Ganapatrao Kulkarni
2024-03-06  5:31     ` Ganapatrao Kulkarni
2024-03-06  8:39     ` Oliver Upton
2024-03-06  8:39       ` Oliver Upton
2024-03-06 13:33     ` Marc Zyngier
2024-03-06 13:33       ` Marc Zyngier
2024-03-06 14:57       ` Ganapatrao Kulkarni
2024-03-06 14:57         ` Ganapatrao Kulkarni
2024-03-05 11:08 ` Marc Zyngier
2024-03-05 11:08   ` Marc Zyngier
2024-03-05 11:13 ` Marc Zyngier
2024-03-05 11:13   ` Marc Zyngier
2024-03-05 13:29   ` Ganapatrao Kulkarni
2024-03-05 13:29     ` Ganapatrao Kulkarni
2024-03-05 15:03     ` Marc Zyngier
2024-03-05 15:03       ` Marc Zyngier
2024-03-05 18:33       ` Ganapatrao Kulkarni
2024-03-05 18:33         ` Ganapatrao Kulkarni
2024-03-06 10:23         ` Marc Zyngier [this message]
2024-03-06 10:23           ` Marc Zyngier
2024-03-26 11:33       ` Ganapatrao Kulkarni
2024-03-26 11:33         ` Ganapatrao Kulkarni
2024-03-27 12:12         ` Marc Zyngier
2024-03-27 12:12           ` Marc Zyngier

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=877cifr75k.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=d.scott.phillips@amperecomputing.com \
    --cc=darren@os.amperecomputing.com \
    --cc=gankulkarni@os.amperecomputing.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oliver.upton@linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.