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
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [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
next prev parent reply other threads:[~2018-03-06 15:23 UTC|newest]
Thread overview: 16+ 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-01 4:14 ` Shanker Donthineni
2018-03-06 13:44 ` Will Deacon
2018-03-06 13:44 ` Will Deacon
2018-03-06 14:47 ` Shanker Donthineni
2018-03-06 14:47 ` Shanker Donthineni
2018-03-06 15:23 ` Will Deacon [this message]
2018-03-06 15:23 ` Will Deacon
2018-03-06 18:48 ` Shanker Donthineni
2018-03-06 18:48 ` Shanker Donthineni
2018-03-06 19:33 ` Shanker Donthineni
2018-03-06 19:33 ` Shanker Donthineni
2018-03-07 10:04 ` Will Deacon
2018-03-07 10:04 ` Will Deacon
2018-03-06 13:52 ` Robin Murphy
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 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.