<klange>
i have done essentially nothing since setting up this uart driver...
<klange>
> 10:02:39 up 2 days, 12:44
<geist>
klange: you've written an ahci and sata driver. question: whats the proper way to determine if the device is a disk or atapi?
<geist>
i wonder if atapi supports the identify command, or maybe the failure of it responding, but yet there being something on the other end (ahci port link status) would imply it's atapi?
<geist>
the osdev wiki says basically by the time you probe the port it's already got the ID word loaded up, but that seems to be only if the bios/etc has previously probed the device, which isn't always the case in my situation
<Mutabah>
Pretty sure ATAPI supports IDENTIFY
<geist>
the situation where the bios hasn't identified it, FWIW, seems to be on qemu on non x86. ie, no bios to initialize it
<klange>
i haven't actually written an ahci driver, but I have written enough of one to suggest that the device type from ahci should tell you
<geist>
my existing code where i was just reading the PORT.sig register was just returning 0 because no firmware had touched it
X-Scale` has joined #osdev
<klange>
oh if that's set by firmware, then I'm no help because that was my suggestion
<bslsk05>
github.com: rust_os/port.rs at master · thepowersgang/rust_os · GitHub
<geist>
what if that's uninitized because nothing talked to it. what is the low level thing to get the sig loaded, etc
X-Scale has quit [Ping timeout: 272 seconds]
X-Scale` is now known as X-Scale
<geist>
the AHCI spec seems to indicate that it's basically a cached copy of a response from a previous command
<Mutabah>
You sure the port you're checking is actually connceted?
<Mutabah>
*connected
<geist>
yah, the link is up, etc and linux works with the same config
<geist>
but it's for ARM qemu so there's no firmware to talk to it previously
<geist>
so the ahci ports are completely uninitialized
<Mutabah>
ah, this has only been checked on x86
<klange>
maybe check sea?
<geist>
if i just ignore the sig and assume it's a disk it works fine
<geist>
but i want to be able to at least properly detect disk vs atapi vs dont-care
<klange>
if arm qemu doesn't do the thing, then that would suggest qemu is not doing it baked into the ahci implementation, so what _is_ the firmware doing?
<bslsk05>
github.com: seabios/ahci.c at master · coreboot/seabios · GitHub
<geist>
it's possible you could just probe it with an IDENTIFY command and if it does't respond, try the PACKET IDENTIFY command (which seems to be a mirror of it, but different)
<geist>
hah there ya go. exactly that
<geist>
they try the packet command first and then try the regularone
<geist>
and from then on out it seems that basically all ATAPI is either IDENTIFY PACKET (0xa1) or PACKET (0xa0) commands
<geist>
then i think if i read the ahci spec right, it'll basically cache the signature in the sig register probabyly as a result of that. it's some sort of error field in the response cmd i think
<klange>
sortie: do you use your editor regularly?
<klange>
thinking about how i started using mine after the big revamp in 2018 and just... kept using it; I haven't edited a single line of code at my current job in vim.
<bslsk05>
tkchia/seabiosify - Experimental fork of SeaBIOS (https://seabios.org) x86 legacy BIOS project, to make it more relocatable (is fork /1 forks/0 stargazers/LGPL-3.0)
<klys>
it's using -flto with a flag -ffat-lto-objects and when removed some gcc-11 segfaults go away
<klys>
except ld does't link and gcc -nostdlib produces /usr/bin/ld: out/rom16.o: error: PHDR segment not covered by LOAD segment
<clever>
klys: ive heard of some bios getting the MMU online before ram, using as few opcodes as possible
<clever>
and that kind of eliminates the need for pic
<klys>
clever, is it demoed somewhere
srjek has quit [Ping timeout: 250 seconds]
<geist>
more of a standard practice
<geist>
thoguh whether or not PC BIOses spend a lot of time with the mmu on i dunno
<klys>
what's the PHDR segment?
<geist>
program header
<klys>
can I dump it with objdump?
<geist>
probably, that or readelf
<geist>
i usually use `objdump -x` when i want it to just dump everything
<geist>
usually gets what i want
<geist>
but looking here i think it's just a program header segment that covers itself, basically
<klys>
I think the LOAD segment is 0 here
<geist>
0 what?
<klys>
since . = 0; isn't specified
<klys>
this bios image links when I say . = 0xe0000;
troseman has quit [Ping timeout: 256 seconds]
sonny has joined #osdev
<klys>
geist, 0 vaddr
<geist>
okay. i have no idea how to help you here
<geist>
i'm just getting fragments of some thing you're working on
<klys>
it's git clone git://github.com/tkchia/seabiosify.git; edit the Makefile to comment out the line with -ffat-lto-objects; make; and then...
<klys>
it produces a linker script with some python, so the linker script could use " . = 0xe0000;" inserted on line 18
<bslsk05>
github.com: seabiosify/layoutrom.py at tkchia/seabiosify · tkchia/seabiosify · GitHub
<klys>
and then make; and it says: Error! Code does not end at 0x100000 (got 0xffff5)
<klys>
so I may need to add eleven nops somewhere
<geist>
so can confirm: a real ATAPI device does not respond to IDENTIFY command
<geist>
qemu's emulated does, though
<geist>
and vice versa actually
<geist>
ah i see. it responds to PACKET_IDENTIFY on disks but fills the results with zero, thus making it an invalid read
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
<sonny>
Why is a tree / hierarchy a popular design for a filesystem?
<sonny>
I think a relation is still suitable even if you don't do database stuff
<klys>
access controls for more inclusive stuff
<sonny>
those could be part of the relation
<klange>
Filesystems aren't really designed around hierarchies, they're just presented that way.
<sonny>
oh, you could've fooled me
<klys>
if you just have everything literally at the top level then you might allow someone else to put stuff there
<klange>
All modern filesystems are essentially "a big uniform table of files" combined with "a huge block pool for the data in those files".
<sonny>
interesting
<sonny>
ok cool
<klange>
Directories are an abstraction built on top of this in which the data of some files is a list of names associated with an element in that first table.
<sonny>
(as an end user I find files pretty useless)
<klys>
if you just want a hierarchy of text then you've gone purely theoretical
<sonny>
not sure what you mean
<klys>
if none of your text contains opcodes (so all of it is legible) then you have no tools
<sonny>
how did it get to opcodes?
<klys>
that's part of the system
* sonny
thinks
<klys>
the system is stored in files that contain code, ad without that you wouldn't be naming your directories anyways.
<sonny>
directories don't matter to the end user?
<klange>
Some end-users love directories.
<sonny>
directories are just for namespacing right?
<sonny>
but it seems like an implementation detail?
<moon-child>
implementation of what?
<moon-child>
for the hierarchical file system, directories and files _are_ the interface
<sonny>
dang it, I got lost in the sauce
<sonny>
I would think the only thing that matters to the user is a name
<klys>
the name would be unconfigured
<sonny>
so it's always expected to understand this hierarchy?
<sonny>
klys what do you mean by that?
<klys>
sonny, in order to bridge the gap between source code and systems binaries, you need to configure your documents to bring order to them.
<klys>
if the only document you have is a name, then it remains unconfigured, meaningless.
<sonny>
I'm just thinking generally, not really about source code and binaries
<moon-child>
I am not saying hierarchies are ideal (because I think otherwise)
<sonny>
but I've just figured out a pretty massive part of my OS to flesh out
<moon-child>
but enforcing global uniqueness of names does not seem right
<klange>
The usual thing that comes up about improving filesystems is indexing / tagging, which are great things and very helpful for users. But they don't require ditching directory structures.
<sonny>
moon-child seems intuitive for a PC OS
<klys>
the user is the user of not just a system, but applications also. so he has to represent and connect your system to needs not expressed in your sources.
<moon-child>
I will also note: the hierarchical filesystem is somewhat unique in its arbitrarily nested hierarchies. Relational databases have database > table > column. Common lisp has package/namespace/name. The web has platform > user > post
<moon-child>
Music collections have artist/album/title
<sonny>
those look like relations to me :P
<klys>
namepsaces look like relations? how expressed?
<moon-child>
(all of these have 3 things. I think lisp actually needs 4 levels, and the web should have only 2; not implying 3 is a sweet spot or anything)
<sonny>
klys ah no I was just thinking of his examples
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
<sonny>
naming is **hard**
<klys>
sometimes I think the web would be better if we just went back to the main six tld's.
<sonny>
there's too many people on the web now for that to happen
<moon-child>
tlds seem rather insignificant
<klys>
I'm still operating out of a subdomain, because I don't want to pay for a dns name
<klys>
it's inconvenient because I can't get indexed with a major search engine
<klys>
well tbh I'm not quite ready for that, because my wiki was getting spammed and my search tool experiment didn't get a valid crawl
<klys>
the wiki is a valid lesson though why trees are better than hierarchies
<klys>
the wiki is a valid lesson though why trees are better than /relations/
<moon-child>
how's that?
<klys>
because if you open yourself up to spam at the top level then you have no control over the resultant amount of data
sonny has quit [Ping timeout: 256 seconds]
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
sonny has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
sonny has quit [Quit: Client closed]
xenos1984 has quit [Remote host closed the connection]
sonny has joined #osdev
xenos1984 has joined #osdev
nick64 has joined #osdev
ElectronApps has joined #osdev
eroux has joined #osdev
goncalo has quit [Ping timeout: 240 seconds]
DonRichie has joined #osdev
<energizer>
you can ask google to crawl you
<klys>
not if you're using a subdomain from freedns.afraid.org that I'm familiar with
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
mlombard has joined #osdev
sonny has quit [Remote host closed the connection]
nyah has joined #osdev
sprock has quit [Ping timeout: 272 seconds]
Burgundy has joined #osdev
Payam has joined #osdev
<Griwes>
...okay this bug was *super* annoying to find. I was getting stack corruption and couldn't figure out why, turns out I was doing "rsp0 = stack_allocation" instead of "rsp0 = stack_allocation + stack_size", and annoyingly that was hitting another stack and using it for interrupts 'from' userspace
<klange>
ah yes, the classic "pre-overflowed stack"
<Griwes>
I need to hide allocating kernel stacks behind a proper abstraction to eliminate this
<Griwes>
mkay, things work now and I'm rather happy, this was irritating me for the past week
<Griwes>
now to fix the thing I new I'd fix next, which is... making sure the kernel thread reading a logging mailbox from userspace actually reads the mailbox before overwriting the buffer sent to the kernel with new data. I'm still pondering on how I want to solve this, but I'll probably... just add a second (third?) mailbox that the kernel puts things into when it's done logging
<Griwes>
(third because the way to give userspace a mailbox is to put a message in a mailbox it has as its entry argument)
sprock has joined #osdev
gog` has joined #osdev
gog` is now known as gog
<Griwes>
yeah that's what I'll do. now I "just" need all the infrastructure for blocking syscalls (I'm going to see if I can manage to use coroutines to persist the state the kernel needs around across the time of the thread being blocked and it being unblocked again)
<Griwes>
but that's not a project for tonight
<sortie>
<klange> sortie: do you use your editor regularly?
<sortie>
Nope, not really. It's been quite buggy although some contributions over the times have stabilized it.
<sortie>
It does work more like the graphical editors I usually use
<sortie>
klange, absolutely the fact that you do use your editor is what's led to its success
<klange>
Pretty much everything I've written since mid 2018 has been in mine. Dogfooding really helps.
<sortie>
I've always been using graphical editors, not command line ones, so that's why
<sortie>
I tend to use a mix of editor(1) and nano(1) casually while on Sortix
pretty_dumm_guy has joined #osdev
the_lanetly_052 has joined #osdev
Payam has quit [Ping timeout: 256 seconds]
pounce has quit [Ping timeout: 240 seconds]
wootehfoot has joined #osdev
pounce has joined #osdev
ss4 has joined #osdev
wootehfoot has quit [Ping timeout: 256 seconds]
GeDaMo has joined #osdev
ss4 has quit [Quit: Leaving]
wootehfoot has joined #osdev
wootehfoot has quit [Read error: Connection reset by peer]
mkopriva has joined #osdev
eroux has quit [Ping timeout: 256 seconds]
masoudd has quit [Ping timeout: 240 seconds]
Payam has joined #osdev
gildasio has joined #osdev
Jari-- has quit [Ping timeout: 272 seconds]
pretty_dumm_guy has quit [Ping timeout: 252 seconds]
pretty_dumm_guy has joined #osdev
pretty_dumm_guy has quit [Client Quit]
pretty_dumm_guy has joined #osdev
pretty_dumm_guy has quit [Client Quit]
pretty_dumm_guy has joined #osdev
pretty_dumm_guy has quit [Client Quit]
mavhq has quit [Ping timeout: 240 seconds]
ravan has quit [Remote host closed the connection]
ravan_ has joined #osdev
blockhead has quit []
CryptoDavid has quit [Quit: Connection closed for inactivity]
pretty_dumm_guy has joined #osdev
heat has joined #osdev
archenoth has joined #osdev
srjek has joined #osdev
heat has quit [Remote host closed the connection]
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 256 seconds]
MelMalik is now known as AmyMalik
[itchyjunk] has joined #osdev
masoudd has joined #osdev
Payam has quit [Quit: Client closed]
sonny has joined #osdev
ElectronApps has quit [Remote host closed the connection]
[itchyjunk] has quit [Ping timeout: 272 seconds]
[itchyjunk] has joined #osdev
[itchyjunk] has quit [Ping timeout: 250 seconds]
[itchyjunk] has joined #osdev
<mrvn>
Griwes: always leave a guard page between kernel allocations
<mrvn>
Griwes: my mailbox is the head of a doubly linked list of messages. No risk of overflowing there.
<bslsk05>
'Monty Python and the Holy Grail - Sir Lancelot' by FDUK200K (00:03:45)
<mrvn>
it's too bad page tables don't have a bit to map huge pages except for the last page.
<GeDaMo>
Do huge pages have to be aligned to 2MB or whatever or just 4K?
<gog>
2MiB pages have to be 2MiB-alinged
<GeDaMo>
Ah
<mrvn>
I haven't used an arch where pages didn't have tp be aligned to the page size. No addition unit in the ,,u
<mrvn>
mmu
<gog>
per the spec, if a PDE has the PSE bit set then bits 12-19 become reserved
<gog>
12-20*
<gog>
also, ftr, i hate intel's nomenclature for their paging structures
<gog>
too complicated
<gog>
PDPTE and PML4E and PDE and
<mrvn>
especially since they are basically identical.
<gog>
all should be called PME (page mapping entries) if they're non-PSE and PTE (page translation entry) if they're PSE or at a first-order table
archenoth has quit [Ping timeout: 240 seconds]
nick64 has quit [Quit: Connection closed for inactivity]
archenoth has joined #osdev
gildasio has joined #osdev
<Griwes>
mrvn: oh I have guard pages, but for stacks they are at the bottom, and the virtual address of the base of the allocation is the end of a new allocation, which means it works as a stack too
<Griwes>
And I didn't mean that the mailbox itself would overflow
<Griwes>
The first process has a log buffer and mailbox sends are async wrt mailbox reads, so it currently manages to reuse the log buffer before the reading side in a kernel thread reads it
<Griwes>
(I'm actively thinking about giving stacks two guard pages, one at the top and one at the bottom)
<moon-child>
yes, you should definitely do that
<moon-child>
(I feel like stack overflow is way more likely to happen in a normal program run than stack underflow)
<gog>
i should probably fix this, but my TCB is at the top of the kernel stack and a stack underflow is gonna trash the thread context lol
<gog>
stack overflow?
<gog>
idk
<gog>
whichever direction it is,it's gonna corrupt program state
<mrvn>
Griwes: if everything has a guard page before itself then after each stack there is a guard page.
<gog>
in this VM region there are two guard pages. one can only tell truths, the other falsehoods
<Griwes>
(guard page) (31 stack pages) <base of the misused allocation here> (guard page) (31 stack pages)
<mrvn>
Griwes: My messages borrow the page so any attempt for the user to acccess the page will fault.-
<Griwes>
So it's hitting the top of another stack instead of a guard page
<mrvn>
Griwes: where is the guard page before the allocation?
<mrvn>
Griwes: you have to put the guard page always on the same side.
<Griwes>
It is on the same side, the bottom of the stack. Maybe for stacks it should just be on top, they are allocated in a very specific way after all...
<mrvn>
Griwes: for stacks it's before the memory, for the rest it is after. that doesn't work.
<Griwes>
We're talking past each other
<mrvn>
Griwes: think about it this way: you always altzernate used memory and guard page.
<Griwes>
Yes that's what happens in the "diagram" above
<mrvn>
(guard page) (31 stack pages) (guard page) <base of the misused allocation here> (guard page) (31 stack pages)
<Griwes>
Guard, 31, guard, 31
<Griwes>
<> is not a set of pages, it's just a marker
<mrvn>
Griwes: why is it 1 page below the start of the stack?
<mrvn>
Did you include the guard page in the size of the stack?
<Griwes>
Because I allocate virtual address space in one go
<Griwes>
This is just an atomic that descends from the bottom of the kernel to allocate space in virtual memory.
sonny has quit [Remote host closed the connection]
<Griwes>
That's the allocator. It's not clever and that's by design
<mrvn>
sure. Still no explanation why the bottom of the stack would be at the start of the guard page.
sonny has joined #osdev
<mrvn>
The address returned by the allocator should be after the guard page. Then your setting the stack wrong would fault as it should.
mahmutov has joined #osdev
<geist>
oh gosh i can't tell you how many times i've screwed up the 'stack ptr initialized to the bottom of the stack' issue
<Griwes>
The allocator is just an address you decrement. But since I use this effectively just for stacks, maybe I should just move the guard page to the top
<Griwes>
But then again if I wrap this in a nice abstraction, hopefully that'll solve it in the long run too
<mrvn>
Griwes: I would to that for all allocations. makes the code easier: void * res = last; last = last + size + PAGE_SIZE; return res;
<mrvn>
+mapping the stack
<mrvn>
did you say decrement? last = last - size - PAGE_SIZE; return last;
<Griwes>
I don't think I'm going to change the core thing, just add an abstraction for allocating and mapping pages together with a guard
<mrvn>
Griwes: but it's irrelevant where you put the guard page for your case. You have 2 stacks so there would be a guard page in the middle no matter what. Unless you return the wrong address in your alocator.
<Griwes>
Okay, once again for the class: the allocator just bumps an address. The client code then maps memory and uses the address. The allocator has no inherent knowledge of guard pages. The abstraction I'll add will have that knowledge.
<mrvn>
Griwes: understood. But I believe you did something wrong with the mapping there. Like map 32 pages instead of the allocated 32.
<mrvn>
-1
<mrvn>
So +1 on making an abstraction. You should allocate 31 physical pages, allocate 32 virtual pages and map 31 pages leaving a guard page.
<Griwes>
I allocated address space for 32 and mapped 31. Then simply pointed rsp0 at the wrong end of the thing because stacks go in a stupid direction. The abstraction will do the same, just return the top of the allocation instead.
<mrvn>
can't be from your description, because that would run into the guard page of the other stack. So check the memory mapping again. There should be an unmapped page at both sides of the stack.
<geist>
i think you two are violently agreeing
<mrvn>
just disagreeing where the likely problem is
<geist>
Griwes: if you're using C++ I found a nice little simple Stack wrapper object works nicely to avoid it. Lets you hide the allocation, track the size separately, and lets you have a little getter function to return it
<bslsk05>
fuchsia.googlesource.com: zircon/kernel/vm/include/vm/kstack.h - fuchsia - Git at Google
<Griwes>
mrvn: there *is* an unmapped page on both sides of the stack. I pointed rsp0 at the base of one of those, except stacks grow down so I didn't run into it.
<mrvn>
Griwes: I know. The question is how you got to that adress at all. That shouldn't be visible to anything at all.
<Griwes>
I allocated address space and mapped the top 31 pages of 32 total and didn't adjust the pointer. Idk what's so hard to get about this
<mrvn>
Griwes: A) that's not what you said at the start, B) only at one point in the code it seems. The other stack you set 32 pages above the allocated address.
<mrvn>
Griwes: anyway, the problem isn't that you didn't add the stack size (that's another bug) but that you forgot to skip the guard page. That's all I'm pointing out.
<Griwes>
That's what I said from the start and yes it was specifically in one place
<geist>
sounds like we can take this problem and stack it on the pile of solved issues?
<Griwes>
I did not forget to "skip" the guard page because I never planned to skip it vOv
<Griwes>
Anyway.
<geist>
problem solved, beaten as if it was a dead horse. you'll never make this mistake again!
<geist>
(believe me, you will)
<geist>
and then one day you'll hit something that uses an upwards growing stack and you'll be screwed up again
<geist>
that was partially what that stack class i was talking about hides, because it also tracks the shadow call stack and safe stack that we use in zircon kernel, and some of those are upwards growing. because they can.
<mrvn>
geist: that fixes the wrong problem (while still a good idea). The guard page handling is the first problem imho.
<geist>
yes yes. i think we all understand that. the guard page can also be wrapped up in that class
<mrvn>
should be inside the allocation function so nothing can get memory without gard page or mess up the guard page.
<geist>
guard pages are a thing and can be solved depending on how your VM works
<geist>
and i 100% disagree with your 'should be inside the alloation function' but i really dont want to argue about it right now
<geist>
that presupposes the allocation function operates in a particular way
dude12312414 has joined #osdev
<geist>
for zircon, for example, we use the VM routines to reserve a larger space from the vm, and then overlap map a smaller region of anonymous memory over the top of it. thus placing one or more guard pages on either side
<geist>
two steps, but that logic can be made into a utility routine
<mrvn>
And I would call thet utility ruotine kallc()
<mrvn>
+o
<geist>
you could, but then you lose the object. because that's not how our VM works
<geist>
when you create a mapping you get a pointer to a handle that you're now responsible for, etc
<geist>
so we dont have any kalloc/kfree style routines
<geist>
this is what i mean about presupposing that an API works a particular way
dude12312414 has quit [Client Quit]
<mrvn>
geist: imho the handle should always have the guard pages already there in the default costructor. You might need a second one for mmap() if you have that syscall but that wouldn't be how e.g. stacks get allocated.
* geist
shrugs
<geist>
agree to disagree
<geist>
guard pgaes are a thing but they're not the end all of it. and the kernel doesn't dictate how user space uses memory
<geist>
it simply gives it the tools it needs to do what it wants
<mrvn>
yeah. And I think there we part our ways. Because I don't trust user space to do anything sane.
<geist>
if user space has some specific reason it doesn't want to have space between its mappings (ie an ELF loader) then let it do what it wants
mavhq has joined #osdev
<geist>
we effectively have guard pages between mappings for standard user mappings because they get ASLR randomized
ravan_ has quit [Ping timeout: 256 seconds]
<geist>
and i think we ensure there's a gap between them, but it's not encoded in the API, as much as 'you cant predict where the mapping is' and thus 'you can't assume it's adjacent to anything'
<geist>
if you want to create mappings that are adjacent you have to jump through hoops with the reservation system i was describing above
<geist>
downside is of course randomized mappings chew through lots of page tables
<mrvn>
same for me. I don't have guard pages baked into the API, just the unpredictability like you do.
<geist>
yah
<geist>
all this aside a very real issue, especially on non x86, with kernel stacks are dealing with stack overflows
<geist>
its one thing to have a guard page, but if you're not ready to handle it (ie, double fault handler on x86 with a proper system panic) then it's kinda moot
<geist>
because you'll just explode and it's hard to debug
<mrvn>
at least you notice immediately.
<geist>
x86 it's fairly easy with the double faults and using a TSS and/or IST
<geist>
with other arches like arm64 or riscv it's fairly tricky because they dont triple fault
<geist>
this is one of those cases where x86 is nice to work with
<geist>
prior to a proper guard page it may make sense to have a 'runaway truck page' where you pre-fill it with a known pattern and check periodically, like on every context switch, if you touched it
<geist>
i've used that with debuglevel=2 on LK on embedded cpus where there's no mmu
<mrvn>
I think ARM never got any double fault stack handling helpers because most OSes switch to the system stack on fault so you only have to get a bunch of opcodes right.
<geist>
to very good effect
<geist>
mrvn: yes but arm64 removed all of that
<geist>
arm32 is mostly irrelevant now
<geist>
(cortex-m being a different arch)
doorzan has joined #osdev
mahmutov has quit [Ping timeout: 256 seconds]
<geist>
riscv i dont see how you can easily do it, to be honest. i looked in various OSes and they haven't solved the stack overflow problem there too
<mrvn>
don't use the stack until you have checked for a double fault.
<geist>
doesn't mean it can't be done, it's just surprisingly tricky. and to a certain extent adding guard pages makes the problem worse
<geist>
mrvn: of course. i'm not an idiot. but it's much more difficult than that
<mrvn>
you have the same problem on x86 too. The double fault handler only happens when the fault itself causes another fault. Not when the handler does.
<geist>
sure but when it does you have a nice clean place where you can do whatevwer code you need
<mrvn>
panic()
<geist>
the cpu has already detected the condition and gives you a nice clean stack
the_lanetly_052_ has quit [Ping timeout: 240 seconds]
<geist>
in the case of arm64 or riscv there's no such detection. it simply faults again and then you're still on the same bad stack you were
<mrvn>
20:30 < mrvn> don't use the stack until you have checked for a double fault.
<geist>
sigh. fine
<mrvn>
in that case load a clean stack and you are in the same boat as x86
<geist>
yes you're right omg why didn't i think of that
* geist
wanders off to do actual work
<mrvn>
it's a few extra opcodes. don't see the difficulty there.
<geist>
go try it and report back
<geist>
there's a reason most oses haven't solved this problem. i only see linux having solved it on arm64, but not riscv
<geist>
none of the BSDs have solved it for either arch
<geist>
because the solution is hairy
<geist>
also to note: the solution also should be *fast* since you have to run the same code on every interrupt and every exception
<mrvn>
linux stores register on the stack on interrupt. can't check the stack limits there without trashing a register unless you have some special temp registers like on arm.
<mrvn>
I guess you could reserve some space through %fs or %gs
<geist>
that's the meat of it. and of course fs/gs is x86 specific
<geist>
and x86 already has the double fault, so that's fine
<geist>
it's the fact that you have no registers to work with on risc machines at the start of the exception
<mrvn>
don't know any risc. Not having any per core/thread register seems like a shotfall though.
<geist>
when i say risc i mean classes of cpus like arm64, mips, riscv, powerpc, etc that usually dont have a stack swap on interrupt/exception
<geist>
and no automatic double fault like mechanism
<geist>
like you get on things like x86 or 68k or probably we32k or so
<geist>
it's not so much of a shortfall that they dont have a core/thread register, it's that its *your* problem to use them as you need to
<geist>
and thus, the problem is a software issue
<mrvn>
aarch64 has the Thread Pointer / ID Register, 2 for EL0.
<geist>
yes but it's a control regster, and you can only access it by loading it into a normal GP register
<geist>
and thus you've trashed one
<mrvn>
write to one, load the other.-
srjek has quit [Ping timeout: 240 seconds]
<geist>
?
<mrvn>
Save x0 to TPIDRRO_EL0 and then load TPIDR_EL0.
<geist>
those are used by user spcae
<geist>
TPIDR_EL1 is what you want, but there's only one
<geist>
and even then that'd only net you exactly one register, which is probably insufficient to actually solve a range check
<mrvn>
indeed. but it gives you access to save registers to offset(x0)
<mrvn>
TPIDRRO_EL0 is read-only from user space, right?
<geist>
yes
<mrvn>
Ok, so TPIDR_EL1 would be the scratch register and TPIDRRO_EL0 the current_thread pointer.
<mrvn>
and TPIDR_EL0 the TLS register
<geist>
possible yes. you're onto something. there are a few solutions to this on arm64, and i'm geting you to go down the proper thought process
<geist>
instead of just dismissing it outright as a trivial solution
<geist>
part of the annoyance is precisely what you're getting onto here: the solution for this tends to dictate how the rest of the kernel can use the TPIDR or whatnot registers, which may be suboptimal elsewhere
<mrvn>
My solution needs at least 2 rgisters. Wether those are banked or special registers doesn't matter. From there you get space to save registers.
<mrvn>
and yeah, that part sucks.
<geist>
now part of the downside is you're doing at least a few extra MSR reads/writes, and a few extra memory accesses. so question is can you optimize it, etc
<geist>
note this is not what linux does. linux has a much more clever and annoying solution that can't be unseen
<mrvn>
I'm trying to avoid code that can't be unseen more than I want speed. :)
<geist>
same
<geist>
note there's *another* line of solution for arm64 that involves using SP_EL0 vs SP_EL1
<geist>
since you can fiddle weith the EL0 SP directly via fiddling with the CurrentSP pseudo register
<geist>
aaand sine you get a different exceptino vector based on a combination of what EL you came from, and what CurrentSP was set to at the time
<geist>
you can build custom code to detect it
<geist>
riscv has none of thise so i dont thin you can easily solve much of this without somewht ike you described where you have to temp save a few regs, do some testing, and then put them back
<mrvn>
For me this isn't any big problem anyway. My microkernel only deals with handling IPC, process creation and switching. And all that runs on the kernel stack and not interrupt stack.
<mrvn>
I just have to make the code that switches to the kernel stack double-fault proof.
<geist>
yah. you can probably always blow the stack due to programming error. but yah it might not be a big risk
<mrvn>
I can easily blow the kernel stack. But that the interrupt handler can check before switching and that part is really small.
<mrvn>
done that plenty of times.
<mrvn>
Point is the interrupt and fault handler always come to a clean stack unless the fault is in that tiny bit of code that switches stacks.
<geist>
yah if you're not reentrant that simplifies things a lot
<geist>
without any VLAs or recursive code you can pretty much statically prove the deepest stack
<mrvn>
It's something you can't do on x86 though, as there is no separate interrupt and system context.
<mrvn>
(unless you set the stack in TSS)
<geist>
or IST. that'd work pretty well on x86-64
<geist>
bt yeah be careful designing too much around arm32isms. the multiple stacks and modes that arm32 has is 'weird'
<geist>
in that nothing else really has that, including arm64
<mrvn>
Luckily x86 has the TTS to select stacks and aarch64 has MSR SPSel, #Imm1
<mrvn>
I thought about that a while back so I wouldn't paint myself into a corner for 64bit support later on.
<mrvn>
I think the plan I came up with back then was to set SP_EL1 to ¤t_thread so I can save registers through that and then load the kernel stack into SP_EL0.
mkopriva has quit []
not_not has joined #osdev
<not_not>
Yo
<not_not>
U wanna hear an insane story?
rustyy has quit [Quit: Lost terminal]
dude12312414 has joined #osdev
<geist>
does it have anything to do with osdev?
<geist>
mrvn: something like that yeah
<geist>
and since the hardware automatically switches to SP_ELx (and thus SP_EL1) on exception you can use it as your anchor to test SP_EL0
masoudd has quit [Ping timeout: 256 seconds]
blockhead has joined #osdev
<mrvn>
geist: Can I do: mov x0, TEMP(sp); mov STACK_LOW(sp), x0; cmp x0, SP_EL0; bge underflow ?
<mrvn>
or do I have to switch the SP before the cmp?
<geist>
are your movs left to right?
<mrvn>
yes
<geist>
i dont think you can compare with SP, but you can load/store from it
<geist>
SP is not a regular register on arm64 so it has a limited set of alu ops that can be done with it
<mrvn>
and it's not sp but the user space SP_EL0
<geist>
not sure you can directly do alu ops against the not-current SP at all
<geist>
since it's basically a MSR at that point
<geist>
but once you make it active you can treat it like SP
<geist>
but then tyu still get a smaller subset of ops
<mrvn>
well, I can always do the MSR to switch stacks. No need to optimize the case where it fails as that hopefully never happens.
rustyy has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
nyah has quit [Ping timeout: 256 seconds]
GeDaMo has quit [Remote host closed the connection]
<not_not>
Geist indirectly yes but then its a very long story
<not_not>
I accidentally got special forces interrogation training by some army people but they got the wrong guy but i passed it
sonny has quit [Remote host closed the connection]
<not_not>
The prelude to it is extremely osdev related tho
srjek has joined #osdev
<not_not>
Nice i got some sdcards from me mom can work at my bootloader for x86_64 soon
<not_not>
Im stuck in the switch to protected mode tho
k8yun has joined #osdev
<geist>
yah i was just the other day thinking what happened to all the 'old' sd cards i had. like pre-2GB
<geist>
because there are multiple versions of the protocol that if you want to write a proper SDMMC driver you hvae to support
<not_not>
U have junkies visit ur house?
<not_not>
Ahh
<geist>
i think i must have tossed them or they're stuffed in old dev boards in boxes
<not_not>
Either ur parents cleaned them or junkies try pawning them for a line
<geist>
SD went through the classically stupid 3 or 4 revs of the protocol where they kept extending the addressing mode so it could access something a bit bigger before they eventually settled on something pretty good
<geist>
same as IDE/ATA
<j`ey>
geist: i have a few 64-128MB USB flash sticks sticks, so nostalgic
<not_not>
Ahhhhh
<not_not>
Shit me too
<kazinsal>
geist: I did the same after my SCSI2SD showed up. I could have sworn I had a box of old SD cards somewhere but I guess they disappeared in a move at some point.
<mrvn>
nothing is as bad as IDE/ATA
<not_not>
I have sharia laws if my parents move a harddrive
<geist>
yah and of course you can't buy anything smaller than like 8GB nowadays easily
<geist>
or at least doesn't make any sense to
<jimbzy>
64MB? Who could fill such a massive drive?
<kazinsal>
so now I've got a brand new fancy 32 GB 120 MB/s UHS-I card in a SCSI2SD that runs at 3.5 MB/s
<not_not>
"mom that was a million dollar company"
<mrvn>
jimbzy: can't fill it, my picture is larger.
<mrvn>
kazinsal: hehe. those disappointed me too
<gog>
640K should be enouh for anybody
<geist>
kazinsal: heh yeah. i had a 36GB 10k rpm drive for the vax, but i eventually just got the scsi2sd and have an install there
<geist>
much easier to move stuff back and forth
<not_not>
I remember the gba cartrige
<geist>
and with multiple LUNs its also easy to load up a cdrom
<jimbzy>
gog, Good times, eh?
<kazinsal>
yeah I've got a couple old 10K SCSI drives on my desk. two of them are holding up one of my monitors!
<mrvn>
I wonder how much the seek speed of scsi2sd helps
<geist>
but on that note i was pleased to see that the vax has no issue addressing stuff like 36GB, even if VMS or old netbsd can't deal with it
<not_not>
I had quantum bits at one point
<not_not>
But paranoia bested me
<kazinsal>
I figured it's probably not worth trying to convince the vax firmware to boot off some weird large IBM SCSI drive though
<geist>
i remember having a quantum bigfoot in college. kinda miss it. if i ever see one cheap i'll grab it
<geist>
even if it doesn't make any sense
<jimbzy>
Again with the VAX? You just have to brag, don't you?
<kazinsal>
the only other working scsi I have is in a Macintosh Classic
<geist>
kazinsal: yah like i said i was pleasantly surprised to see that i has no issue
<gog>
doesn't adrian black live in portland? go down and ask him for one he's probably got a stack
<kazinsal>
jimbzy: mine is still stuck in eBay purgatory :(
<mrvn>
geist: That's the beauty of software driven disk interfaces. You can just bit-bang the modern protocol on it and get 36GB disks to work.
<geist>
kazinsal: yep, i got a second scsi2sd 50 pin one for a mac SE. also works like a champ. can just attach it directly to the back of the mac
<not_not>
Wich is the prelude to how i was mistakenly trained by the army in torture redistance
<jimbzy>
kazinsal, That stinks.
<kazinsal>
I'm still waiting on the bespoke console cable though so it's fine
<geist>
gog: yah honeslty i'm waiting for the computer club meetings to start again. might even drive down to portland for one of them. they seem to have some good clubs there
<gog>
he seems like a good dude i wanna hang out with him :p
<geist>
yah totally
<geist>
i think at this point i've seen prety much every video he's done in the last 2 or 3 years
<geist>
slowly working backwards in time
<not_not>
Who codepukse?
<gog>
i've been watching MMMC's lately while dozing off
<gog>
he gets some neat stuff from viewers
<geist>
he and big clive are pleasing to listen to across the room, even if you're not actively watching it
<gog>
very much so
<gog>
not_not: no, adrian's digital basement
<not_not>
Ahh
<geist>
yah watching adrian take apart enough macs is why i eventually started looking for and got a mac SE recently
<gog>
i've got the itch now though, kinda want to go to the e-cycler's and see if i can rescue an old computer to play with
<gog>
nice
<geist>
and scored a real straight up Apple ][ original
<kazinsal>
ooh, neat, you can return to canada with a rapid antigen test now instead of needing a whole hog expensive PCR test... might be time to head down to seattle for a weekend soon
<not_not>
I get a pcr test a day
<geist>
yah and they have a lot of testing in the airport, though that seems a bit too risky for me
<kazinsal>
yeah, biggest issues with the PCR test requirement was the cost and the delay
<kazinsal>
it's fine if you're spending a week somewhere but it makes day trips infeasible
<not_not>
Im in an institution atm so its all handy
<jimbzy>
I deeply regret getting rid of my old gear years ago, but that's life I suppose.
<kazinsal>
this spring I'll probably end up doing a day trip down to the connections museum or something
<not_not>
Ill go on a vacation
<geist>
i did get rid of some pretty good stuff before i moved up here, but was mostly due to size. but i didn't throw it away, sold it to people at work for cheap
<mrvn>
send your mobile virtual presence unit
<geist>
mostly so that i was sure they were true fans and not just going to flip it or something
<geist>
which seems to be a real issue nowadays on ebay, vs 5 or 6 years ago
<geist>
seems a sizable amount of vintage gear is untested flipped stuff
<jimbzy>
I was more into home computers, though. I mean, how could you not love a CoCo?
<not_not>
Mmm i want a crt monitor
<kazinsal>
yeah, I was pleasantly surprised when I got a message from the seller of my vax saying they were replacing the RTC battery
<kazinsal>
shows that they actually care
<geist>
yah! i have been keeping an eye out for a coco 3, but they're hard. have a coco 2
vdamewood has quit [Read error: Connection reset by peer]
<klange>
i still have a bunch of crap in a storage unit in oakland, but nothing museum-worthy
<not_not>
Getting some crts
<jimbzy>
Lovely little machines.
<jimbzy>
Way better than my Mattel Aquarius II
vdamewood has joined #osdev
<Matt|home>
...does anyone know how hard it is to get on one of the bsd core dev teams..
<Matt|home>
im looking for an OSS project i can hop on that'll eventually lead to something os dev related
<geist>
well, you dont really need to be on the core team for that i'd assume
<not_not>
Matt cant be hard i was trained by special forces in interrogation in resistance to interrogation by mistake and passef
<geist>
but may help to find some project and do it
<geist>
that might be hard
<not_not>
Pased
<Matt|home>
?????
<Matt|home>
what the hell does special forces have to do with anything
<Matt|home>
geist : if you have any suggestions im all ears..
<kazinsal>
pay that no mind
<geist>
well, i dont unfortunatkey. i'd assume all the low hanging fruit is already done
<klange>
If you want to work on something osdev-related, then work on something osdev-related
<kazinsal>
maybe subscribe to a few of the openbsd mailing lists? poke around on -bugs and -tech and -misc and see if there's anything there that you can contribute to
<not_not>
Only few days later when i asked if i should go to basic training and join the army they realized they had trained the wrong guy lmao
<not_not>
"and all you want is some pills???" R u ok?
<not_not>
Sweet its all rainy and cozy outside
k8yun has quit [Quit: Leaving]
<gog>
i've started working on a tutorial. i have part 1 nearly done
<gog>
idk why. hit a wall with my project. inspiration has left me
<mrvn>
you need a bigger hammer :)
<mrvn>
what is part 1?
<klange>
my inspiration comes in waves
<klange>
> 07:58:37 up 3 days, 10:40
gxt has quit [Ping timeout: 240 seconds]
gxt has joined #osdev
<kazinsal>
I keep thinking maybe I can re-inspire myself to work on my project if I just do <laundry list> first
<kazinsal>
and then I go and buy some dumb stuff from ebay instead ;)
<mrvn>
kazinsal: I'm binge watching amazon prime.
<kazinsal>
heh, I started watching Farscape the other night. good show
<mrvn>
kazinsal: spoiler alert, there will be wormholes.
<kazinsal>
seems to be part of the core premise, yeah
<gog>
mrvn: setting up environment, makefile and creating a hello world for uefi
<gog>
part 2 i'm throwing the reader into the deep end
<mrvn>
environment, makefile and creating a hello world for uefi done properly?
<gog>
yes
<kazinsal>
nice
<gog>
whatever that means
<gog>
but with clang
<gog>
if that's what you mean :D
<gog>
i'm off of bedrest now though and picked up a pet care gig tomorrow
<gog>
idk if i'm ready for dog walking though
<jimbzy>
Cheers, gog
<gog>
i'm not supposed to run, jump or lift heavy objects for at least another month and my main dog walk client is basically a 40 minute crossfit workout :|
Burgundy has quit [Ping timeout: 240 seconds]
<jimbzy>
Sounds like it needs a good trainer.
<gog>
i have some experience with that and i do what i can
<kazinsal>
:toot: congrats on being allowed to move around
<mrvn>
don't overdo it
<mrvn>
take a wheelchair and tie the dogs to it and go dog sleddign.