On 2025-01-29 7:12 a.m., Yash Shinde wrote:
On 29-01-2025 06:08, Alistair Francis wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
On Wed, Jan 29, 2025 at 1:51 AM Randy MacLeod via
lists.openembedded.org
<[email protected]> wrote:
Add Raj, Khem, Kexin and Zhe who know more about RISC-V than I do.
Kexin and Zhe are on holiday for a week or more.
CC a few people who have contributed to riscv* conf.
I am not all that familiar with either qemu internals or riscv specifications
so any input is appreciated.
I have some comments and questions below.
On 2025-01-28 5:16 a.m.,[email protected] wrote:
From: Yash Shinde<[email protected]>
Currently, GCC Asan supports only Sv39 on RISC-V due to custom allocator
configurations optimized for large allocations.
These configurations are incompatible with larger address spaces like Sv48/Sv57.
This fix enables RISC-V's configuration for Sv39 by default when running
`runqemu nographic`,
eliminating the need for manual configuration via command line flags
(`qemuparams="-cpu rv64, sv39=true"`).
Fixes [YOCTO #15691]
https://bugzilla.yoctoproject.org/show_bug.cgi?id=15691
Reference:https://git.openembedded.org/openembedded-core/commit/?id=4b4450ff695ef73bf7a2437e142d2e0730d6a547
Signed-off-by: Yash Shinde<[email protected]>
---
meta/conf/machine/include/riscv/qemuriscv.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/conf/machine/include/riscv/qemuriscv.inc
b/meta/conf/machine/include/riscv/qemuriscv.inc
index d01d988eee..6170ce65f2 100644
--- a/meta/conf/machine/include/riscv/qemuriscv.inc
+++ b/meta/conf/machine/include/riscv/qemuriscv.inc
@@ -27,6 +27,7 @@ UBOOT_ENTRYPOINT:riscv64 = "0x80200000"
# qemuboot options
QB_SMP ?= "-smp 4"
QB_KERNEL_CMDLINE_APPEND = "earlycon=sbi"
+QB_CPU = "-cpu rv64, sv39=true"
Thanks Yash.
To save everyone from doing the math, sv39 gives the system 512 GB virtual
address space.
Should we use the ?= operator here so that users can easily override this
specification
just as is done for QB_SMP two lines above?
Please summarize what testing you did.
I tested a buffer overflow case for asan by booting qemuriscv64 and
using the command "runqemu nographic",
without passing any additional qemu parameters, as mentioned in the
follow-up message to the patch:
https://lists.openembedded.org/g/openembedded-core/message/210317
Did you test with TCLIBC=musl ?
Musl builds for asan are still broken as mentioned earlier in
"gcc-sanitizers.inc" :
/
# musl is currently broken entirely
COMPATIBLE_HOST_libc-musl = 'null'/
http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/gcc/gcc-sanitizers.inc#n88
When built with TCLIBC="musl", following error is seen:/
"gcc-sanitizers RPROVIDES libasan but was skipped: incompatible with
host riscv64-poky-linux-musl (not in COMPATIBLE_HOST)"/
Since you are changing qemuriscv.inc you and the YP AB should test qemuriscv32
and qemuriscv64.
qemuriscv32 should, if I'm understanding how this works, be unaffected since it
has to use sv32 mode.
As mentioned in the below gcc mailing list, risc-v 32 does not
officialy support GCC's ASan and some of other 32-bit targets. So,
this should not affect it.
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557406.html
Also, there is no compatible host for riscv-32 in gcc-sanitizers.inc:
https://git.openembedded.org/openembedded-core/commit/?id=7d90d2a70f0184ad715e9917d3e7aa096cf98f79
Note: While testing this I found that the "-cpu rv64, sv39=true" also
passes when building for risc-v 32.
I will send a V2 where it only applies to risc-v 64.
Thanks for duplicating and explaining your testing. I noticed your test
email after I had replied
to the main thread because you didn't CC me on the testing email. Oops
... on both our parts.
Anyway, this started out being about just GCC ASan but if you're
changing qemu's config,
you'll have to build that emulator and use it a bit before sending in
v2. Perhaps run the full
GCC test suite and say openssl's ptests. The rest of the ptest will
likely be run as part of the YP AB
testing.
Did you find out why sv39 isn't the default for qemu?
QEMU defaults to the max supported SATP mode. I'm not sure there is a
specific reason, that's just what we have always done since we allowed
a user to specify the SATP mode.
Supporting to the above comments, here is the commit that allows users
to specify the SATP mode
https://github.com/qemu/qemu/commit/6f23aaeb9be13d4a26b7f863533c316105481640
It seems that Risc-V has multiple sizes for addressable memory and
Linux probes for the machine's support at startup.
Thus, the reason would be to give the flexibility to users to set it
rather than having a fixed default SATP mode.
The authors/reviewers of the commit can put more light on this topic.
If not, please check the git history and it there isn't an answer there, ask
one of the qemu developers
who work on risc-v. It would be nice to have a sentence about that in the
commit log.
Did you consider a different RISC-V cpu sub-arch such as rva22s64 ?
I think defaulting to a profile (RVA22S64) would be the way to go,
that will also enable a known set of extensions.
Alistair
https://github.com/qemu/qemu/commit/3ba8462c4ca55720239fdc6fa30b9870d22a8814
I'm only asking because it seems like it might be a good fit for us and I
noticed it when
searching the qemu commit logs looking for sv39.
I added "-cpu rv64,sv39=true" options for risc-v by default as
mentioned in the bug requirements.
The support for RVA22S64 looks good to have provided that it doesn't
break other risc-v builds/tests being done in Yocto.
Following commit adds the RVA22S64 profile and corresponding
extensions in qemu.
https://github.com/qemu/qemu/commit/af651969eb23ecf018bcaa8e0761b58425de550c
<https://github.com/qemu/qemu/commit/af651969eb23ecf018bcaa8e0761b58425de550c>I
also tested with passing /"QB_CPU = "-cpu rv64i, rva22s64=true"" /in
/qemuriscv.inc/ file and asan works with that as well.
Good.
I will send a V2 with setting "rva22s64" profile for risc-v 64 only as
follows:
*/QB_CPU:riscv64 ?= "-cpu rv64, rva22s64=true"/
*
Using the weak operator "?=" to allow overrides seems like a good choice
at least for now.
Do you really need both
"-cpu rv64, rva22s64=true"
rather than just:
"-cpu rva22s64"
?
Remember, I don't know much about the qemu internals so maybe this is
obvious to you.
../Randy
**
Regards,
Yash
../Randy
QB_MACHINE = "-machine virt"
QB_DEFAULT_BIOS = "fw_jump.elf"
QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
--
# Randy MacLeod
# Wind River Linux
--
# Randy MacLeod
# Wind River Linux
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#210411):
https://lists.openembedded.org/g/openembedded-core/message/210411
Mute This Topic: https://lists.openembedded.org/mt/110856569/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
