All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: Gavin Shan <gshan@redhat.com>
Cc: kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org,
	maz@kernel.org, james.morse@arm.com, suzuki.poulose@arm.com,
	yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
	qperret@google.com, ricarkol@google.com, tabba@google.com,
	bgardon@google.com, zhenyzha@redhat.com, yihyu@redhat.com,
	shan.gavin@gmail.com
Subject: Re: [PATCH] KVM: arm64: Fix soft-lockup on relaxing PTE permission
Date: Wed, 6 Sep 2023 16:29:56 +0000	[thread overview]
Message-ID: <ZPipBOzdM9lj/uO9@linux.dev> (raw)
In-Reply-To: <bfdafdc5-4abf-a387-0857-e8cb84e4b3d7@redhat.com>

Gavin,

On Wed, Sep 06, 2023 at 08:26:24AM +1000, Gavin Shan wrote:

[...]

> It seems I didn't make it clear enough. The reason why I had the concern
> to avoid reading ctr_el0 is we read ctr_el0 for twice in the following path,
> but I doubt if anybody cares. Since it's a hot path, each bit of performance
> gain will count.
> 
>   invalidate_icache_guest_page
>   __invalidate_icache_guest_page   // first read on ctr_el0, with your code changes
>   icache_inval_pou(va, va + size)
>   invalidate_icache_by_line
>     icache_line_size               // second read on ctr_el0

That can be addressed by shoving the check deep into
invalidate_icache_by_line, which would benefit _all_ use cases of
I-cache invalidation by VA. I haven't completely made up my mind about
that, though, because of the consequences of a global invalidation.

> > > @size is guranteed to be PAGE_SIZE or PMD_SIZE aligned. Maybe
> > > we can just aggressively do something like below, disregarding the icache thrashing.
> > > In this way, the code is further simplified.
> > > 
> > >      if (size > PAGE_SIZE) {
> > >          icache_inval_all_pou();
> > >      } else {
> > >          icache_inval_pou((unsigned long)va,
> > >                           (unsigned long)va + size);
> > >      }                                                          // parantheses is still needed
> > 
> > This could work too but we already have a kernel heuristic for limiting
> > the amount of broadcast invalidations, which is MAX_TLBI_OPS. I don't
> > want to introduce a second, KVM-specific hack to address the exact same
> > thing.
> > 
> 
> Ok. I was confused at the first glance since TLB isn't relevant to icache.
> I think it's fine to reuse MAX_TLBI_OPS here, but a comment may be needed.
> Oliver, could you please send a formal patch for your changes?

Yeah, I think I may have said it before, but this thing needs to be
called 'MAX_DVM_OPS'. I-cache invalidations and TLB invalidations become
DVMOps (Distributed Virtual Memory) in terms of CHI, which pile up at the
miscellaneous node in the mesh.

Give me a day or two to convince myself of the right way to go about
this and I'll send out what I have.

-- 
Thanks,
Oliver

  reply	other threads:[~2023-09-06 16:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-04  7:28 [PATCH] KVM: arm64: Fix soft-lockup on relaxing PTE permission Gavin Shan
2023-09-04  8:04 ` Oliver Upton
2023-09-05  0:06   ` Gavin Shan
2023-09-05 18:06     ` Oliver Upton
2023-09-05 22:26       ` Gavin Shan
2023-09-06 16:29         ` Oliver Upton [this message]
2023-09-19  6:41           ` Gavin Shan
2023-09-04  8:22 ` Marc Zyngier
2023-09-05  1:44   ` Gavin Shan

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=ZPipBOzdM9lj/uO9@linux.dev \
    --to=oliver.upton@linux.dev \
    --cc=bgardon@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=gshan@redhat.com \
    --cc=james.morse@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=qperret@google.com \
    --cc=ricarkol@google.com \
    --cc=shan.gavin@gmail.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=will@kernel.org \
    --cc=yihyu@redhat.com \
    --cc=yuzenghui@huawei.com \
    --cc=zhenyzha@redhat.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 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.