Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Wed, 25 Nov 2020 10:49:18 +0000
From:   Marc Zyngier <maz@kernel.org>
To:     David Brazdil <dbrazdil@google.com>
Cc:     kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, James Morse <james.morse@arm.com>,
        Julien Thierry <julien.thierry.kdev@gmail.com>,
        Suzuki K Poulose <suzuki.poulose@arm.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>, Dennis Zhou <dennis@kernel.org>,
        Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@linux.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
        Quentin Perret <qperret@google.com>,
        Andrew Scull <ascull@google.com>,
        Andrew Walbran <qwandor@google.com>, kernel-team@android.com
Subject: Re: [PATCH v2 06/24] kvm: arm64: Move hyp-init params to a per-CPU
 struct
In-Reply-To: <20201125103946.2unmclsdfqpr3eyk@google.com>
References: <20201116204318.63987-1-dbrazdil@google.com>
 <20201116204318.63987-7-dbrazdil@google.com> <87lfes5f54.wl-maz@kernel.org>
 <20201125103946.2unmclsdfqpr3eyk@google.com>
User-Agent: Roundcube Webmail/1.4.9
Message-ID: <643459b9146c5cdf91c3316bb1cb096e@kernel.org>
Precedence: bulk

On 2020-11-25 10:39, David Brazdil wrote:
> On Mon, Nov 23, 2020 at 02:20:07PM +0000, Marc Zyngier wrote:

[...]

>> > +
>> > +	/*
>> > +	 * Flush the init params from the data cache because the struct will
>> > +	 * be read while the MMU is off.
>> > +	 */
>> > +	__flush_dcache_area(params, sizeof(*params));
>> 
>> nit: please use kvm_flush_dcache_to_poc(), as it clearly indicates to
>> which point we are flushing.
> 
> Will change, but out of curiosity - how is it different? AFAICT, it is 
> just
> an alias with a single use in __clean_dcache_guest_page:
> 
>   #define kvm_flush_dcache_to_poc(a,l)	__flush_dcache_area((a), (l))

It is indeed the exact same thing, but it says clearly in the name that 
we
are cleaning to the "Point Of Coherency", as opposed to any other 
architectural level (Unification or Persistence).

It makes it clear that we are cleaning all the way to the point where it 
can
be accessed reliably with an uncacheable mapping, and not leaving the 
data
dangling at a shallower cache level.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...