public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Shanker Donthineni <shankerd@codeaurora.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Philip Elcan <pelcan@codeaurora.org>,
	Vikram Sethi <vikrams@codeaurora.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	kvmarm <kvmarm@lists.cs.columbia.edu>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v6] arm64: Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC
Date: Tue, 6 Mar 2018 15:23:19 +0000	[thread overview]
Message-ID: <20180306152318.GE17454@arm.com> (raw)
In-Reply-To: <d6182273-c23a-c4fa-ce40-c87055bfb338@codeaurora.org>

Hi Shanker,

On Tue, Mar 06, 2018 at 08:47:27AM -0600, Shanker Donthineni wrote:
> On 03/06/2018 07:44 AM, Will Deacon wrote:
> > I think this is a slight asymmetry with the code for the I-side. On the
> > I-side, you hook into invalidate_icache_by_line, whereas on the D-side you
> > hook into the callers of dcache_by_line_op. Why is that?
> > 
> 
> There is no particular reason other than complexity of the macro with another 
> alternative. I tried to avoid this change by updating __clean_dcache_area_pou().
> I can change if you're interested to see both I-Side and D-Side changes are
> symmetric some this like this...
> 
>  .macro dcache_by_line_op op, domain, kaddr, size, tmp1, tmp2
>   
>   .if	(\op == cvau)
>   alternative_if ARM64_HAS_CACHE_IDC
>         dsb	ishst
>         b       9997f
>   alternative_else_nop_endif
>   .endif
> 
> 	dcache_line_size \tmp1, \tmp2
> 	add	\size, \kaddr, \size
> 	sub	\tmp2, \tmp1, #1
> 	bic	\kaddr, \kaddr, \tmp2
>  9998:
> 	.if	(\op == cvau || \op == cvac)
>  alternative_if_not ARM64_WORKAROUND_CLEAN_CACHE
> 	dc	\op, \kaddr
>  alternative_else
> 	dc	civac, \kaddr
>  alternative_endif
> 	.elseif	(\op == cvap)
>  alternative_if ARM64_HAS_DCPOP
> 	sys 3, c7, c12, 1, \kaddr	// dc cvap
>  alternative_else
> 	dc	cvac, \kaddr
>  alternative_endif
> 	.else
> 	dc	\op, \kaddr
> 	.endif
> 	add	\kaddr, \kaddr, \tmp1
> 	cmp	\kaddr, \size
> 	b.lo	9998b
> 	dsb	\domain
> 9997:
> 	.endm

I think it would be cleaner the other way round, actually -- move the check
out of invalidate_icache_by_line and into its two callers.

> > I notice that the only user other than
> > flush_icache_range/__flush_cache_user_range or invalidate_icache_by_line
> > is in KVM, via invalidate_icache_range. If you want to hook in there, why
> > aren't you also patching __flush_icache_all? If so, I'd rather have the
> > I-side code consistent with the D-side code and do this in the handful of
> > callers. We might even be able to elide a branch or two that way.
> > 
> 
> Agree with you, it saves function calls overhead. I'll do this change...
> 
> static void invalidate_icache_guest_page(kvm_pfn_t pfn, unsigned long size)
> {
> 	if (cpus_have_const_cap(ARM64_HAS_CACHE_DIC)
> 	    __invalidate_icache_guest_page(pfn, size);
> }
> 
> 
> > I'm going to assume that I-cache aliases are all coherent if DIC=1, so it's
> > safe to elide our alias sync code.
> > 
> 
> I'm not sure about I-cache whether aliases are all coherent if DIC=1 ot nor.
> Unfortunately I don't have any hardware to test DIC=1. I've verified IDC=1.

I checked with our architects and aliases don't pose a problem here, so you
can ignore me :)

Will

  reply	other threads:[~2018-03-06 15:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-01  4:14 [PATCH v6] arm64: Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC Shanker Donthineni
2018-03-06 13:44 ` Will Deacon
2018-03-06 14:47   ` Shanker Donthineni
2018-03-06 15:23     ` Will Deacon [this message]
2018-03-06 18:48       ` Shanker Donthineni
2018-03-06 19:33         ` Shanker Donthineni
2018-03-07 10:04           ` Will Deacon
2018-03-06 13:52 ` Robin Murphy

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=20180306152318.GE17454@arm.com \
    --to=will.deacon@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=pelcan@codeaurora.org \
    --cc=robin.murphy@arm.com \
    --cc=shankerd@codeaurora.org \
    --cc=vikrams@codeaurora.org \
    /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