Hi,
On 17/07/2023 16:31, Ayan Kumar Halder wrote:
+ xen-devel (Since the question is related to Xen on Arm in general).
On 14/07/2023 15:14, Michal Simek wrote:
+xen
On 7/14/23 16:11, Michal Simek wrote:
Hi Stefano,
I am playing with running u-boot on the top of xen
(xenguest_arm64_defconfig) based on ask from Kris to run QNX on the
top of it.
In past we found that QNX requires to have DCACHE off before it's start.
Chris found in past that dcache off is not working and he passed this
to us to take look at it more.
Xen will not prevent the guest to turn off D-cache. BTW, on Armv8, the
cache is never really off, it is just by-passed. So a guest running with
MMU/D-Cache off has to be a lot more careful when writing/reading data.
That's why I enabled cache commands to be able to run dcache off and
see the hang as Kris.
Can you provide more details on the hang? What is QNX trying to do?
What's the instruction it is blocked on?
Also, which version of Xen are you using?
I found one interesting commit created by Marc for Android which were
taken back to u-boot upstream. It is talking about KVM and I barely
understand what he is talking about.
I of course enabled this option to try it and behavior is the same.
That's why my question is what Xen is doing in connection to dcache
operations.
WRT cache operations, Refer
https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=53b705d02cec03861044e673536586bd1b2443bd
When the data abort is caused due to cache maintenance for an address,
there are three scenarios:-
I might be missing some context. From my understanding, Michal is
referring an hang. This may or may not be a data abort. Do you have more
details you could share?
[...]
commit 46dc54287031759c03c68902283d92076938305c
Author: Marc Zyngier <m...@kernel.org>
AuthorDate: Thu Feb 9 04:54:27 2023 +0800
Commit: Tom Rini <tr...@konsulko.com>
CommitDate: Mon Mar 6 17:03:55 2023 -0500
arm: cpu: Add optional CMOs by VA
Exposing set/way cache maintenance to a virtual machine is
unsafe, not
least because the instructions are not permission-checked but also
because they are not broadcast between CPUs. Consequently, KVM
traps and
emulates such maintenance in the host kernel using by-VA operations
I am not sure if Xen behave in same way (ie traps and emulates *all*
cache maintenance instructions).
@Julien, Stefano, Bertrand - Do you know more about this ?
Xen will emulate set/way instructions only when the P2M is not shared
with the IOMMU (i.e there is no device passthrough for Arm). Otherwise,
a fault will be injected to the domain. Even when emulating, the
performance will be quite bad, so it is best to avoid them all together.
By any chance, are you passthrough-ing a device and QNX is using set/way?
and
looping over the stage-2 page-tables. However, when running under
protected KVM, these instructions are not able to be emulated
and will
instead result in an exception being delivered to the guest.
Introduce CONFIG_CMO_BY_VA_ONLY so that virtual platforms can
select
this option and perform by-VA cache maintenance instead of using
the
set/way instructions.
Signed-off-by: Marc Zyngier <m...@kernel.org>
Signed-off-by: Will Deacon <willdea...@google.com>
Signed-off-by: Pierre-Clément Tosi <pt...@google.com>
[ Paul: pick from the Android tree. Fixup Pierre's commit. And
fix some
checkpatch warnings. Rebased to upstream. ]
Signed-off-by: Ying-Chun Liu (PaulLiu) <paul....@linaro.org>
Cc: Tom Rini <tr...@konsulko.com>
Link:
https://android.googlesource.com/platform/external/u-boot/+/db5507f47f4f57f766d52f753ff2cc761afc213b
Link:
https://android.googlesource.com/platform/external/u-boot/+/2baf54e743380a1e4a6bc2dbdde020a2e783ff67
Code ends when it tries to call
set_sctlr(sctlr & ~(CR_C|CR_M));
Here is implementation. I confirm EL level which is obviously EL1.
180 static inline void set_sctlr(unsigned long val)
181 {
182 unsigned int el;
183
184 el = current_el();
185 if (el == 1)
186 asm volatile("msr sctlr_el1, %0" : : "r" (val) :
"cc");
187 else if (el == 2)
188 asm volatile("msr sctlr_el2, %0" : : "r" (val) :
"cc");
189 else
190 asm volatile("msr sctlr_el3, %0" : : "r" (val) :
"cc");
191
192 asm volatile("isb");
193 }
Is there any reason why it is not possible to clear to sctlr_el1
CR_C/CR_M - cache disabling, MMU disabling?
I am not sure I understand the question. The code '& ~(CR_C|CR_M)' which
means all the bits but C/M will be cleared. IOW, the cache will be
disabled and the MMU disabled as well.
IIUC, above you said, this is what QNX requires.
Cheers,
--
Julien Grall
