public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
To: Wonhyuk Yang <vvghjk1234@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [Question] arm64: head: invalidating stale cache with mmu off
Date: Tue, 17 Nov 2020 11:18:55 +0800	[thread overview]
Message-ID: <20201117111855.0298e544@xhacker.debian> (raw)
In-Reply-To: <CAEcHRTq6qvB0ne5vAOg=tgAPCq72oSrSSUCvXbaOx=EC6TZF9w@mail.gmail.com>

On Tue, 17 Nov 2020 09:52:10 +0900 Wonhyuk Yang wrote:


> 
> 
> Hi, I have a question about dmb barriers in arm64's head.S.
> In the head.S, I could see the pattern below several times.
> 
> str w0, [x1]
> dmb sys
> dc ivac, x1   // Invalidate potentially stale cache line
> 
> I found that,
> arm64: head: fix cache flushing and barriers in set_cpu_boot_mode_flag
> commit: d0488597a1b71
> explained this code.
> 
> > This patch reworks the broken flushing code so that we:
> >
> > (1) Use a DMB to order the strongly-ordered write of the cacheline
> > against the subsequent cache-maintenance operation (by-VA
> > operations only hazard against normal, cacheable accesses).
> >
> > (2) Use a single dc ivac instruction to invalidate any clean lines
> > containing a stale copy of the line after it has been updated.
> > Use a DMB to order the strongly-> ordered write of the cacheline  
> 
> But I still don't  understand why the store operation should precede the
> dc operation.
> 
> Is there any problem, if the dc operation precedes the store operation?
> 

Just my opinion:
If dc op precedes the store, speculatively fetch of system cache or arch
cache for guest os after the dc could still bring coherence problems when
the var is checked later. I.E consider below sequence:

dc ivac

speculatively fetch of system cache or arch cache for guest os

str	w20, [x1]

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

  reply	other threads:[~2020-11-17  3:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-17  0:52 [Question] arm64: head: invalidating stale cache with mmu off Wonhyuk Yang
2020-11-17  3:18 ` Jisheng Zhang [this message]
2020-11-17  8:53   ` Ard Biesheuvel

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=20201117111855.0298e544@xhacker.debian \
    --to=jisheng.zhang@synaptics.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=vvghjk1234@gmail.com \
    --cc=will.deacon@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox