terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #riscv
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #riscv
MaxGanzII has joined #riscv
heat has joined #riscv
aredridel has quit [Read error: Connection reset by peer]
aredridel has joined #riscv
junaid_ has quit [Remote host closed the connection]
jay321 has joined #riscv
meta-coder has joined #riscv
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #riscv
meta-coder has quit [Read error: Connection reset by peer]
Andre_Z has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
MaxGanzII has quit [Ping timeout: 240 seconds]
heat has quit [Remote host closed the connection]
heat has joined #riscv
<bjdooks>
drewfustini: ok, i'll be in 3rd-9th
prabhakarlad has quit [Quit: Client closed]
somlo has quit [Ping timeout: 240 seconds]
somlo has joined #riscv
<drewfustini>
jrtc27: thank you for the explanation
terminalpusher has quit [Ping timeout: 245 seconds]
jay321 has quit [Remote host closed the connection]
jay321 has joined #riscv
jay321 has quit [Ping timeout: 240 seconds]
BootLayer has quit [Quit: Leaving]
elastic_dog has quit [Read error: Connection reset by peer]
elastic_dog has joined #riscv
<pierce>
<another|> "more RVV 0.71 hw? urg" <- Why urg? I'm pretty keen to see the xthead vector stuff get merged so it can actually be used
<pierce>
At least what conchuod alluded to there shouldn't be anything blocking it anymore
<another|>
I want 1.0 he already. Not gonna write asm for incompatible draft versions.
<another|>
*hw
<pierce>
Don't write asm?
<pierce>
Just compile for whatever version
<another|>
Not gonna cut it.
MaxGanzII has joined #riscv
<pierce>
If you target 0.7.1 it works on 1.0 too
<another|>
courmisch tells me there are differences
BootLayer has joined #riscv
awita has joined #riscv
via_c7 has quit [Remote host closed the connection]
jacklsw has joined #riscv
via_c7 has joined #riscv
Armand has quit [Ping timeout: 246 seconds]
<pierce>
Between 0.7.1 and 1.0? Sure, I'm not denying that.
<pierce>
As I said, If you target 0.7.1 it works on 1.0 too
<muurkha>
jrtc27: and side-effecting reads, I assume?
<muurkha>
pierce: pretty common for compilers to be inadequate at vectorizing
<another|>
pierce: I've been hearing they're incompatible. Now you tell me they're not?
<jrtc27>
pierce: if people stop producing hardware with implementations of ancient drafts then there is less of a push to support it in toolchains and the world can be a happier place
<jrtc27>
supporting V is already complicated enough
<geist>
is the supervisor state the same between those revisions?
<geist>
ie, same size vector registers etc?
<pierce>
<another|> "Pierce: I've been hearing they'..." <- Incompatible if you write V1.0 vector code and expect it to run on v0.7.1, yes
<pierce>
<jrtc27> "Pierce: if people stop producing..." <- I don't disagree
<pierce>
But because of people trying to bury non V1.0 vectors, there's dead silicon being shipped in the only RISC-V vector extension on the market today
<pierce>
<muurkha> "Pierce: pretty common for..." <- I'm not suggesting autovectorisation of code
<jrtc27>
they have had years to update their implementation
<jrtc27>
I have a tiny amount of sympathy for them shipping the draft when they did
<jrtc27>
I have no sympathy for them continuing to do so
<pierce>
Btw disclaimer, the compatibility remark doesn't come from me, as I'm no authority on the ISA and whatnot. But it came from the co-author of the vector extension. You can put two and two together to ascertain who that is.
<another|>
pierce: meh. Not feeling like it. I'll target 1.0
meta-coder has joined #riscv
MaxGanzII has quit [Ping timeout: 240 seconds]
<pierce>
another|: Enjoy running it on no hardware then ig?
<jrtc27>
my understanding is there is a useful non-empty subset of v0.7.1 and v1.0 that is compatible, but that subset is only compatible at the machine code level, not even the assembly syntax level
<pierce>
jrtc27: This is what I'm lead to believe also
<pierce>
The subset is quite high from what I was told
<another|>
I can spent the waiting time writing x86
<muurkha>
geist: that's an especially interesting question
<muurkha>
another|: or CUDA
<another|>
muurkha: I don't like writing code for HW I don't have
via_c7 has left #riscv [Leaving]
<muurkha>
another|: even if you can't get RVV 1.0 hardware, you can get NVIDIA hardware
<muurkha>
or RVV 0.7.1 evidently
MaxGanzII has joined #riscv
<another|>
Not feeling like dealing with their proprietary driver mess. Also: money
<muurkha>
yeah, money
<muurkha>
it's a hit
motherfsck has joined #riscv
<another|>
still waiting on that tree to grow from the bills I buried. Any day now
<courmisch>
another|: instruction encoding is incompatible; in most (but not all) cases, you could work around it by assembling again
<courmisch>
another|: at least that's what I get by comparing the specs. I don't have hardware implementing either version
<courmisch>
other problem, there is no kernel support as of yet, so you can presumably only use Vectors in privileged mode
<another|>
yeah, I have a patched kernel running in qemu. qemu-user needs no kernel support though
<courmisch>
AFAIK, QEMU can only emulate 1.0
<courmisch>
maybe someday I'll actual write about what the actual differences are
<courmisch>
been meaning to do it, but procrastination is strong
<pierce>
<courmisch> "other problem, there is no..." <- Was there 0.7.1 patches waiting on the sidelines? Or would the work on V1 need to be completed first?
<another|>
older qemu had 0.7.1 IIRC
<another|>
but yeah. 8.0 only has 1.0
<courmisch>
pierce: I have seen patches. Don't know if they were tied to one version or which
<muurkha>
courmisch: I'd be very interested in reading your notes!
<pierce>
courmisch: Yeah I was thinking of asking Mr Vector Co-author to do the same, possibly with a implementation guide too
<muurkha>
I wonder if we can get 0.7.1 back into qemu; that'd be pretty helpful for testing code that is intended to also run on the hardware that actually exists already
<another|>
there a new thead-c906 cpu option in qemu 8.0
<another|>
not sure if that includes their V
<muurkha>
sweet
<pierce>
muurkha: I don't know if that will happen. The powers to be at the pointy end want it buried
<muurkha>
pierce: hey, I've run Linux with patches that aren't in Linus's tree, I can patch QEMU
<jrtc27>
there is a massive gulf between the amount of maintenance burden that comes with supporting 0.7.1 in the assembler and supporting 0.7.1 in an emulator
prabhakarlad has joined #riscv
jacklsw has quit [Quit: Back to the real life]
jay321 has joined #riscv
meta-coder has quit [Ping timeout: 240 seconds]
<drewfustini>
I finally got enough lab time to bisect the 6.4-rc1 boot failure ("Oops - store (or AMO) access fault [#1]") on an internal SoC that runs upstream 6.3 okay.
<drewfustini>
The commit before 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping") is boots okay. 3335068f8721 fails in PID 1 with "Oops - store (or AMO) access fault [#1]"
<drewfustini>
I'll form this all into a cohesive email and post it to the linux-riscv but I thought I would bounce it off the channel first.
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<drewfustini>
jrtc27: thanks, do you mean that Linux might be missing a sfence.vma instruction?
aredridel has joined #riscv
<jrtc27>
hm, maybe not, there's a local_flush_tlb_all() call somewhere after create_linear_mapping_page_table
<jrtc27>
I wonder
rurtty has joined #riscv
<jrtc27>
best_map_size picks the size based on the PA
<jrtc27>
but the VA also needs to be that aligned
<jrtc27>
is your RAM not very aligned?
<jrtc27>
uh
<jrtc27>
hm
awita has quit [Ping timeout: 264 seconds]
<jrtc27>
BUG_ON((PAGE_OFFSET % PGDIR_SIZE) != 0);
<jrtc27>
so that should match up
<jrtc27>
given kernel_map.va_pa_offset = PAGE_OFFSET - phys_ram_base;
<jrtc27>
so __va(pa) % PGDIR_SIZE == pa % PGDIR - phys_ram_base % PGDIR_SIZE == -phys_ram_base % PGDIR
aerkiaga has joined #riscv
<drewfustini>
The BUG_ON is in arch/riscv/mm/init.c ?
<jrtc27>
uh
<jrtc27>
this gets complicated, uh
<jrtc27>
yes
<muurkha>
drewfustini: congrats
<jrtc27>
if you want to rule out VA/PA alignment mismatch as a possibility (I'm struggling to understand the spaghetti code here), I'd suggest tweaking best_map_size to also take the va and apply the same checks to it as pa before returning a given size
<jrtc27>
or BUG_ON if the pa check passes but the va one fails
<jrtc27>
so you can observe it happening (as otherwise even if it "fixes" your issue who knows if that's just by chance due to perturbed binary layout)
<drewfustini>
thank you for the suggestion
<jrtc27>
some BUG_ONs (maybe behind ifdefs if expensive) in create_p*_mapping asserting that va and pa are suitably aligned wouldn't go amiss...
<drewfustini>
you asked "is your RAM not very aligned?". Did you mean the data structures in the kernel, or the physical memory addresses in the SOC?
aredridel has quit [Read error: Connection reset by peer]
aredridel has joined #riscv
<drewfustini>
I don't think any of the memory mapped register blocks for the various peripherals are misaligned. But I'll boot it back up prior to the breaking commit and take a closer look
<drewfustini>
What sort of misalignment would be a problem? I am all the MMIO registers are aligned on 4 byte boundaries but I have not considered it closely before
<drewfustini>
s/I am/I think/
danilogondolfo has quit [Remote host closed the connection]
<jrtc27>
not really sure
<jrtc27>
hard to juggle in my head
<jrtc27>
just don't get warm fuzzy feelings from this code