MyNetAz has quit [Remote host closed the connection]
<JohnHenry>
Does RISC-V Linux assign an ASID per `mm` and then use the same ASID on all harts for that context; or can it assign different ASIDs to different harts for the same `mm`?
<JohnHenry>
I ask because I saw discussion on RISC-V lists a while ago about how the RISC-V spec doesn't say anything about different ASIDs between cores, and a RISC-V ASID is a hart-local thing so an OS could use different ASIDs for the same process and page table. My brief examination of Linux suggests that's not what's happening here but I'd feel better if a credible human agreed.
<bjdooks>
JohnHenry: I'm fairly sure ASID is meant to be the same across all cores,
cleger has joined #riscv
hexdump0815 has joined #riscv
cousteau has joined #riscv
hexdump0815 has quit [Ping timeout: 252 seconds]
ungeskriptet has quit [Ping timeout: 265 seconds]
ungeskriptet_ has joined #riscv
ungeskriptet_ is now known as ungeskriptet
hexdump0815 has joined #riscv
agentcasey_ has joined #riscv
agentcasey has quit [Ping timeout: 244 seconds]
MyNetAz has quit [Remote host closed the connection]
fuwei has joined #riscv
MyNetAz has joined #riscv
* bjdooks
is wondering if there's a open fpga core that we could add big-endian to as a new project for more fpga type people
alifib has quit [Ping timeout: 246 seconds]
yongxiang has quit [Excess Flood]
yongxiang has joined #riscv
* cousteau
isn't sure he likes the idea of big endian
<cousteau>
(except in the context of tools to convert data from and to big endian)
yongxiang has quit [Excess Flood]
yongxiang has joined #riscv
<bjdooks>
cousteau: don't look at any internet protocol then
<cousteau>
yeah that'd fall in the "tools to convert data" category
<cousteau>
just to clarify... were you suggesting adding native big endian support, like the whole processor using big endian as the native format, or just adding instructions to handle big endian?
<cousteau>
because the latter is OK, the former is the one that makes me sort of uncomfortable
<cousteau>
...then again, I suppose all that'd be needed would be an option to load and store data in one order or the other
* cousteau
thinking on what a "big endian risc-v core" would imply
<bjdooks>
cousteau: the latest ISA has a {x}STATUS flag that changes the load/store unit's endian
<cousteau>
oof, that can get tricky
<bjdooks>
we've done that for OpenSBI, QEMU, Kernel and a few other prijects
<bjdooks>
the fun comes running little-endian guest on a big endian system
<cousteau>
where can I read info on that?
<xypron>
We have those macros __efi_runtime_data, __efi_runtime_code
* cousteau
is happy he guessed right about the "it only affects the load/store unit" part
<xypron>
sorry wrong channel
<cousteau>
xypron: ok so it'll affect data only and not instructions
<cousteau>
because afaik the RISC-V ABI only makes sense in little endian
<cousteau>
er, ISA, not ABI
<cousteau>
xypron: oh OK, that wasn't related then :)
<cousteau>
Were did the 2019 spec go? I remember there used to be a page in riscv.org with a link to it. Now googling "risc-v spec" no longer shows that page, and it took me a while browsing from riscv.org directly to get to the specs
<cousteau>
also, I see that the specs seem to be hosted in google drive. Just so that you know, some companies cut access to google drive because "security", so if the only official place to download the specs is google drive that can be a problem
<cousteau>
"RISC-V base ISAs have either little-endian or big-endian memory systems, with the privileged architecture further defining bi-endian operation. Instructions are stored in memory as a sequence of 16-bit little-endian parcels, regardless of memory system endianness. Parcels forming one instruction are stored at increasing halfword addresses, with the lowest-addressed parcel holding the lowest-numbered bits in the instruction specification."
<cousteau>
ok that makes sense I guess. So instructions always little, data may be big or little but that's only related to how stuff is stored in memory. Kinda weird but it feels "safe enough" to not make me uncomfortable.
cousteau has quit [Quit: Leaving]
jedesa has joined #riscv
fuwei has quit [Quit: Konversation terminated!]
jedesa has quit [Remote host closed the connection]
hmw has quit [Quit: Bye.]
<bjdooks>
is the north americna summit announced yet?
ganboing has joined #riscv
<ganboing>
The privileged spec does say the following about different ASIDs between harts, quote:
<ganboing>
If a hart employs an address-translation cache, that cache must appear to be private to that hart. In
<ganboing>
particular, the meaning of an ASID is local to a hart; software may choose to use the same ASID to
<ganboing>
refer to different address spaces on different harts.
hmw has joined #riscv
JRepin has quit [Quit: Konversation terminated!]
JRepin has joined #riscv
<bjdooks>
ah, I might have been thinking that "other" architecture
paulk has quit [Ping timeout: 248 seconds]
paulk has joined #riscv
heat has joined #riscv
* bjdooks
is trying to work out if he can do the OSS-Tokyo and RISCV-NA double bill again this year
Tenkawa has joined #riscv
ungeskriptet_ has joined #riscv
damian101_ has joined #riscv
ungeskriptet has quit [Ping timeout: 268 seconds]
ungeskriptet_ is now known as ungeskriptet
MyNetAz has quit [Remote host closed the connection]
damian101 has quit [Ping timeout: 244 seconds]
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #riscv
<geertu>
bjdooks: And LPC-Tokyo?
<bjdooks>
geertu: possibly
<bjdooks>
knowing date/loc for the rv summit would make life easier, but suppose i have a few months to book things
<palmer>
bjdooks: there's a note in the priv spec saying ASIDs might be made global in the future, that's probably what you're thinking of?
vagrantc has joined #riscv
wgrant has joined #riscv
EchelonX has joined #riscv
rconjoe_ has quit [Ping timeout: 268 seconds]
paulk has quit [Read error: Connection reset by peer]
paulk has joined #riscv
yongxiang has quit [Excess Flood]
yongxiang has joined #riscv
stolen has joined #riscv
EchelonX has quit [Quit: Leaving]
wgrant has quit [Ping timeout: 252 seconds]
jjido has joined #riscv
wgrant has joined #riscv
jjido has quit [Quit: My laptop has gone to sleep. ZZZzzz…]
coldfeet has quit [Quit: Lost terminal]
cow321 has quit [Ping timeout: 248 seconds]
BootLayer has quit [Quit: Leaving]
MyNetAz has quit [Remote host closed the connection]
MyNetAz has joined #riscv
getz has quit [Quit: A mystery...]
getz has joined #riscv
ganboing has quit [Remote host closed the connection]
MyNetAz has quit [Remote host closed the connection]
naoki has joined #riscv
Trifton has quit [Remote host closed the connection]
Trifton has joined #riscv
stolen has quit [Quit: Connection closed for inactivity]
MyNetAz has joined #riscv
Trifton has quit [Quit: TOADiE v1.2 - Raid [SLAM] <It's time for a reinstall... HeHeHe>]
ganboing has joined #riscv
cow321 has joined #riscv
rconjoe has joined #riscv
jjido has joined #riscv
rconjoe has quit [Quit: WeeChat 4.5.1]
rconjoe has joined #riscv
rconjoe has quit [Client Quit]
rconjoe has joined #riscv
<JohnHenry>
palmer: that is what lead me to this question, but what I was wondering was about Linux's ASID behavior. It appears to be ASID-per-process despite the hart-private callout. Is that right?
<JohnHenry>
hart-private callout in the RISC-V spec, that is
<palmer>
IIRC that's the case, but I'd have to check the code to know for sure (I didn't write it)
<JohnHenry>
I was looking at it and that was the impression I got but I am also not very confident about Linux despite my masters project becoming a Linux hack
<JohnHenry>
thus asking. :)
<JohnHenry>
thanks!
<palmer>
looking at it, I think they're not quite strictly global: we track them globally for allocation, but we don't eagerly globally flush them. So they're almost global, but I think they can be different when rolling over generations. Not 100% sure on that
naoki has quit [Quit: naoki]
naoki1 has joined #riscv
<palmer>
I seem to remember thinking we could get better allocation by avoiding the global tracking, but I think we did it this way because it was less overhead to do the tracking. So not clear which would result in better performance, and this works so it's kind of just good enough for now
<palmer>
at the time there was no HW. I think there's some now, but I don't remember anyone complaining about performance. So maybe it's good enough, but I bet we're just not doing complicated enough workloads for people to care
<heat>
do ASIDs even matter for $CURRENTYEAR riscv?
naoki1 is now known as naoki
<palmer>
well, they don't make QEMU go faster... ;)
<palmer>
it's still early in the year, though, so maybe someone will build some HW someone cares about at some point...
hightower2 has quit [Remote host closed the connection]
hightower2 has joined #riscv
rconjoe_ has joined #riscv
rconjoe has quit [Ping timeout: 268 seconds]
MyNetAz has quit [Remote host closed the connection]