From: Sean Anderson <seanga2@gmail.com>
To: u-boot@lists.denx.de
Subject: [PATCH 1/7] Revert "riscv: Clear pending interrupts before enabling IPIs"
Date: Thu, 10 Sep 2020 06:18:23 -0400 [thread overview]
Message-ID: <7c5419f5-fd16-05d1-369b-dd43edefd3da@gmail.com> (raw)
In-Reply-To: <CAN5B=e+y7SFFx8JkAxopVc5t0jcoWw84XF2z4oPER1AM1JyBbA@mail.gmail.com>
On 9/10/20 2:39 AM, Rick Chen wrote:
> Hi Sean
>
>> On 9/9/20 3:50 AM, Rick Chen wrote:
>>> Hi Sean
>>>
>>>> Clearing MIP doesn't do anything. Whoops. The following commits should
>>>> tackle this problem in a more robust manner.
>>>
>>> I still not catch your points about that this commit 947263033 really
>>> help to fix pending IPIs not clean problem on k210 platform at that
>>> time, but you just said it do nothing and remove it here currently.
>>
>> After refactoring the original smp patch to remove the null check, I
>> neglected to re-test with a debug uart enabled. Without doing that test,
>> it is impossible to catch the pending IPI bug. The secondary hart will
>> crash before the serial driver is initialized. I didn't do that test at
>> the time, because I was mostly worried about the secondary hart
>> corrupting the device tree and causing the boot to fail. That failure
>> mode was fixed by 40686c394. So I saw that and thought that the pending
>> IPI issue was solved as well.
>
> Can you describe more clearly why with a debug uart enabled will
> trigger the pending IPI bug ?
It doesn't trigger the bug, it always happens. However, if there is no
debug uart nothing gets printed, because it occurs before the serial
driver is initialized.
>
> And why the pending IPI be raised and not clear before jump to U-Boot ?
I don't know. Presumably the boot rom raises it to signal to jump to
U-Boot and never clears it.
>
> Why the
> csrc MODE_PREFIX(ip), t0
> don't help to fix this bug ?
The problem is that MSIP in MIP is not necessarily writable.
> Each lower privilege level has a separate software interrupt-pending
> bit (HSIP, SSIP, USIP), which can be both read and written by CSR
> accesses from code running on the local hart at the associated or any
> higher privilege level. The machine-level MSIP bits are written by
> accesses to memory- mapped control registers, which are used by remote
> harts to provide machine-mode interprocessor interrupts.
> Interprocessor interrupts for lower privilege levels are implemented
> through ABI, SBI or HBI calls to the AEE, SEE or HEE respectively,
> which might ultimately result in a machine- mode write to the
> receiving hart?s MSIP bit. A hart can write its own MSIP bit using the
> same memory-mapped control register.
Contrast for example with SSIP in SIP
> Three types of interrupts are defined: software interrupts, timer
> interrupts, and external interrupts. A supervisor-level software
> interrupt is triggered on the current hart by writing 1 to its
> supervisor software interrupt-pending (SSIP) bit in the sip register.
> A pending supervisor-level software interrupt can be cleared by
> writing 0 to the SSIP bit in sip. Supervisor-level software interrupts
> are disabled when the SSIE bit in the sie register is clear.
I originally added this at your suggestion, but I never ended up
testing it separately from the IPI cleanup patch.
--Sean
next prev parent reply other threads:[~2020-09-10 10:18 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-07 18:16 [PATCH 0/7] riscv: Correctly handle IPIs already pending upon boot Sean Anderson
2020-09-07 18:16 ` [PATCH 1/7] Revert "riscv: Clear pending interrupts before enabling IPIs" Sean Anderson
2020-09-09 7:50 ` Rick Chen
2020-09-09 10:23 ` Sean Anderson
2020-09-10 6:39 ` Rick Chen
2020-09-10 10:18 ` Sean Anderson [this message]
2020-09-11 7:38 ` Bin Meng
2020-09-11 10:22 ` Sean Anderson
2020-09-11 14:45 ` Bin Meng
2020-09-11 18:30 ` Sean Anderson
2020-09-14 3:10 ` Rick Chen
2020-09-14 12:45 ` Sean Anderson
2020-09-07 18:16 ` [PATCH 2/7] riscv: Match memory barriers between send_ipi_many and handle_ipi Sean Anderson
2020-09-11 7:45 ` Bin Meng
2020-09-07 18:16 ` [PATCH 3/7] riscv: Use NULL as a sentinel value for smp_call_function Sean Anderson
2020-09-09 8:33 ` Rick Chen
2020-09-09 9:01 ` Rick Chen
2020-09-09 10:16 ` Sean Anderson
2020-09-09 10:26 ` Heinrich Schuchardt
2020-09-09 10:36 ` Sean Anderson
2020-09-10 8:09 ` Rick Chen
2020-09-14 3:21 ` Rick Chen
2020-09-11 8:04 ` Bin Meng
2020-09-14 1:58 ` Leo Liang
2020-09-14 2:07 ` Bin Meng
2020-09-14 6:10 ` Leo Liang
2020-09-14 6:15 ` Bin Meng
2020-09-14 14:05 ` Sean Anderson
2020-09-07 18:16 ` [PATCH 4/7] riscv: Clear pending IPIs on initialization Sean Anderson
2020-09-14 2:08 ` Bin Meng
2020-09-07 18:16 ` [PATCH 5/7] riscv: Add fence to available_harts_lock Sean Anderson
2020-09-10 3:26 ` Rick Chen
2020-09-11 10:39 ` Sean Anderson
2020-09-11 14:47 ` Bin Meng
2020-09-07 18:16 ` [PATCH 6/7] riscv: Ensure gp is NULL or points to valid data Sean Anderson
2020-09-14 5:25 ` Bin Meng
2020-09-14 13:03 ` Sean Anderson
2020-09-14 13:27 ` Sean Anderson
2020-09-07 18:16 ` [PATCH 7/7] riscv: Add some comments to start.S Sean Anderson
2020-09-14 5:26 ` Bin Meng
2020-09-09 2:02 ` [PATCH 0/7] riscv: Correctly handle IPIs already pending upon boot Rick Chen
2020-09-09 2:38 ` Sean Anderson
2020-09-09 2:44 ` Sean Anderson
2020-09-10 7:08 ` Rick Chen
2020-09-10 10:49 ` Sean Anderson
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=7c5419f5-fd16-05d1-369b-dd43edefd3da@gmail.com \
--to=seanga2@gmail.com \
--cc=u-boot@lists.denx.de \
/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