etra has quit [Read error: Connection reset by peer]
etra has joined #riscv
etra has quit [Changing host]
etra has joined #riscv
emdevt has quit [Ping timeout: 248 seconds]
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
Stat_headcrabbed has joined #riscv
Stat_headcrabbed has quit [Client Quit]
naoki has quit [Quit: naoki]
<Esmil>
in qemu 10 what is the difference between -cpu rva23s64 and -cpu rva23u64 ?
<Esmil>
i thought rva23s64 was just the rva23 requirements for s-mode and rva23u64 was the rva23 requirements for u-mode
<Esmil>
..but then you'd need both to run a full rva23 machine/emulation right?
psydroid3 has joined #riscv
<sorear>
From a profile spec perspective they are mutually exclusive, since it describes the environment/application interface and that is at a single mode for a given application; the s64 requirements are mostly a superset so that normal supervisors will turn s64 into u64
<Esmil>
gotcha
<Esmil>
in other words you should be able to run a the userspace of a rva23 distro on a rv23u64 machine, but it might need a special kernel to deal with missing rva23s64 features?
<sorear>
In other words "rva23u64 machine" is incoherent because u64 only applies to environments which directly provide U-mode, like qemu linux-user
paulk has quit [Ping timeout: 255 seconds]
<sorear>
"rva23s64" likewise only applies to environments _including_ a SBI implementation and it's somewhat wrong to use it to describe a bare metal environment, but there are currently no *m64 profiles so it's the best we have
<Esmil>
sorear: ah, so i wonder how how qemu-*system*-riscv64 implements rva23u64
<Esmil>
since it rva23u64 only says anything about the u-mode
<sorear>
shorthand for a list of extensions, which are visible in all modes because that's how qemu implements them
<sorear>
and means they don't have to have different options for linux-user vs softmmu
<Esmil>
right. so that would effectively mean what I wrote above. rva23 userspace would run, but the kernel might be confused about missing rva23s64 extensions
<xypron>
Esmil: The server platform spec requires RVA23S64 and Ubuntu 25.10 has the same requirement.
<Esmil>
xypron: yeah, of course
<xypron>
Userspace would be only partially usable.
paulk has joined #riscv
paulk has joined #riscv
<sorear>
I don't think it makes sense to talk about userspace running when the kernel doesn't. ecall is as much a part of the user ISA as czero.eqz is
<xypron>
Esmil: Zifencei is for instance in the RVA23S64 profile bt used by OpenJDK
ldevulder has quit [Ping timeout: 248 seconds]
ldevulder has joined #riscv
edolnx_ has joined #riscv
edolnx has quit [Ping timeout: 260 seconds]
dcz has joined #riscv
ilya15557 has joined #riscv
ilya15557 has quit [Remote host closed the connection]
patersonc has quit [Quit: Connection closed for inactivity]
dcz has quit [Read error: Connection reset by peer]
Andre_Z has joined #riscv
edolnx_ has quit [Ping timeout: 260 seconds]
dcz has joined #riscv
ruidx has joined #riscv
<palmer>
Esmil: FWIW, the kernel doesn’t really care much about the profiles, so it’s basically just detecting extensions and trying to figure out what to do. Thus you’d probably be fine with these mixed setups — it’d just see all the extensions in rva23u64, enable those, and then enable whatever supervisor stuff you have as well
hightower2 has joined #riscv
dcz has quit [Quit: Konversation terminated!]
ruidx has quit [Quit: WeeChat 3.8]
<Esmil>
palmer: exactly. that's what i'd expect
patersonc has joined #riscv
<palmer>
Ya, and the specs don't really get specific enough about the split between U and S mode to say a lot else there
<palmer>
(like rva23s64 having zifencei, which is part of the unpriv spec)
dramforever[m]1 has joined #riscv
<dramforever[m]1>
i do think the idea is that rva23u64 is what the kernel can expect, and in turn the kernel can say if you give me an rva23s64 machine i'll give you an rva23u64 userspace
<dramforever[m]1>
ugh
<dramforever[m]1>
"rva23s64 is what the kernel can expect"
<palmer>
In practice vendors just do whatever they want, so we don't really expect anything in the kernel ;)
<palmer>
But ya, I think that's generally the idea
<dramforever[m]1>
wondering maybe we should probably eventually have some way to have like some way to build linux with the no extra state extensions enabled