From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: Libre-RISCV General Development <libre-riscv-dev@lists.libre-riscv.org>
Subject: Re: [libre-riscv-dev] Avoiding Spectre or Meltdown
Date: Mon, 18 May 2020 14:26:29 +0100
Message-ID: <CAPweEDzowZLPCpdMtivUGeTd7u73ppBb1jqB8MDbOtvX4TdKVg@mail.gmail.com> (raw)
In-Reply-To: <33B8ACFA-9A9F-482F-985B-D5E5C44B56B9@gatech.edu>
On Monday, May 18, 2020, Yehowshua <yimmanuel3@gatech.edu> wrote:
> I know Jacob mentioned some scheme earlier.
>
> If you shadow commits to memory(really cache) during speculation by having
> commits placed in a buffer, which you can ignore once branch is resolved,
> wouldn’t that avoid some problems with Spectre and Meltdown?
hmm hmm i honestly do not know. my understanding of these OoO issues is
limited.
* we can calculate the Effective Address (immediate or indexed) and i
deliberately put in a "hold" system (addr.request and addr.go), so even
starting the actual LDST can be shadowed (defined as a prohibition against
committing).
* when addr.go is sent, there will be either a "address is ok" or an
exception signal comes back.
* a ST will subsequently wait for an explicit "st.go" however LD at present
assumes it may proceed at any time
therefore at the moment, it is the address computation which can proceed
speculatively without causing "spec/melt" harm.
however beyond the "addr.go" point, the assumption is that if no exception
comes back, all resources required to complete the LD or ST have been
reserved (TLBs established, L1 cache line valid and held) and there is a
100% guarantee that the operation will succeed.
how those API rules interact with spec/melt i do not really know.
i *believe* it is that you are not allowed to attempt "speculative
anything" which could cause an exception, is that right?
if that is the case we will need to hold all addr.go firing until any form
of shadowing (branches etc) are 100% clear.
this would result in performance that completely sucks, especially in tight
inner loops.
i would advocate making it possible to set a bit that changes that
behaviour at the hardware level (supervisor bit).
l.
--
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
next prev parent reply index
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-18 13:03 Yehowshua
2020-05-18 13:26 ` Luke Kenneth Casson Leighton [this message]
2020-05-18 18:41 ` Jacob Lifshay
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=CAPweEDzowZLPCpdMtivUGeTd7u73ppBb1jqB8MDbOtvX4TdKVg@mail.gmail.com \
--to=lkcl@lkcl.net \
--cc=libre-riscv-dev@lists.libre-riscv.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
Libre RISC-V Mailing list Archives (accessible via public-inbox)
Archives are clonable: git clone --mirror https://inbox.libre-soc.org/libre-riscv-dev
Example config snippet for mirrors
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git