Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Caleb Connolly <caleb.connolly@linaro.org>
To: Konrad Dybcio <konrad.dybcio@linaro.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Cc: Bjorn Andersson <andersson@kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Douglas Anderson <dianders@chromium.org>,
	Rob Clark <robdclark@gmail.com>
Subject: Re: [PATCH] soc: qcom: cmd-db: map shared memory as WT, not WB
Date: Wed, 27 Mar 2024 23:29:09 +0000	[thread overview]
Message-ID: <cd549ee8-22dc-4bc4-af09-9c5c925ee03a@linaro.org> (raw)
In-Reply-To: <f4ebe819-9718-42c3-9874-037151587d0c@linaro.org>



On 27/03/2024 21:06, Konrad Dybcio wrote:
> On 27.03.2024 10:04 PM, Volodymyr Babchuk wrote:
>>
>> Hi Konrad,
>>
>> Konrad Dybcio <konrad.dybcio@linaro.org> writes:
>>
>>> On 27.03.2024 9:09 PM, Volodymyr Babchuk wrote:
>>>> It appears that hardware does not like cacheable accesses to this
>>>> region. Trying to access this shared memory region as Normal Memory
>>>> leads to secure interrupt which causes an endless loop somewhere in
>>>> Trust Zone.
>>>>
>>>> The only reason it is working right now is because Qualcomm Hypervisor
>>>> maps the same region as Non-Cacheable memory in Stage 2 translation
>>>> tables. The issue manifests if we want to use another hypervisor (like
>>>> Xen or KVM), which does not know anything about those specific
>>>> mappings. This patch fixes the issue by mapping the shared memory as
>>>> Write-Through. This removes dependency on correct mappings in Stage 2
>>>> tables.
>>>>
>>>> I tested this on SA8155P with Xen.
>>>>
>>>> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
>>>> ---
>>>
>>> Interesting..
>>>
>>> +Doug, Rob have you ever seen this on Chrome? (FYI, Volodymyr, chromebooks
>>> ship with no qcom hypervisor)
>>
>> Well, maybe I was wrong when called this thing "hypervisor". All I know
>> that it sits in hyp.mbn partition and all what it does is setup EL2
>> before switching to EL1 and running UEFI.
>>
>> In my experiments I replaced contents of hyp.mbn with U-Boot, which gave
>> me access to EL2 and I was able to boot Xen and then Linux as Dom0.
> 
> Yeah we're talking about the same thing. I was just curious whether
> the Chrome folks have heard of it, or whether they have any changes/
> workarounds for it.

Does Linux ever write to this region? Given that the Chromebooks don't
seem to have issues with this (we have a bunch of them in pmOS and I'd
be very very surprised if this was an issue there which nobody had tried
upstreaming before) I'd guess the significant difference here is between
booting Linux in EL2 (as Chromebooks do?) vs with Xen.

Volodymyr: have you tried booting the kernel directly from U-Boot in
EL2? Can you confirm if this issues also happens then?
> 
> Konrad

-- 
// Caleb (they/them)

  reply	other threads:[~2024-03-27 23:29 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-27 20:09 [PATCH] soc: qcom: cmd-db: map shared memory as WT, not WB Volodymyr Babchuk
2024-03-27 20:45 ` Konrad Dybcio
2024-03-27 21:04   ` Volodymyr Babchuk
2024-03-27 21:06     ` Konrad Dybcio
2024-03-27 23:29       ` Caleb Connolly [this message]
2024-03-28  9:58         ` Stephan Gerhold
2024-03-29  0:40           ` Stephen Boyd
2024-04-11  3:54             ` Elliot Berman
2024-04-11  4:43               ` Stephen Boyd
2024-04-10 22:12           ` Volodymyr Babchuk
2024-04-11  8:02             ` Stephan Gerhold
2024-04-11  8:41               ` Stephen Boyd
2024-03-28 21:29         ` Volodymyr Babchuk
2024-03-28 11:12 ` Nikita Travkin
2024-03-28 14:06   ` Nikita Travkin
2024-03-28 12:01 ` Maulik Shah (mkshah)
2024-03-28 22:19   ` Volodymyr Babchuk
2024-03-29  4:52     ` Maulik Shah (mkshah)
2024-07-12 10:23       ` Pavan Kondeti

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=cd549ee8-22dc-4bc4-af09-9c5c925ee03a@linaro.org \
    --to=caleb.connolly@linaro.org \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andersson@kernel.org \
    --cc=dianders@chromium.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robdclark@gmail.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