<jaevanko>
They are 32 bit values, and the vector table starts at 0 unless the implementation says otherwise, so qemu probably just leaves it there
<doug16k>
thanks
<geist>
also remember arm64 cores start on the highest EL level that is implemented. so unless you're literally writing the EL3 code (which you might be here)
<geist>
you're not really dealing with the raw reset vector
<doug16k>
I am the -bios
<klange>
< geist> what are you using? ← One of ToaruOS's oldest 'primitives': a pipe! Should probably be using a queue with distinct objects with its own blocking semaphore...
<geist>
yah then probably so
vdamewood has quit [Read error: Connection reset by peer]
<bslsk05>
github.com: qemu-rom/dispi.cc at master · doug65536/qemu-rom · GitHub
<doug16k>
that rom probably works as is in bochs too
<doug16k>
I wanted to keep adding secondary-vga until pci couldn't handle any more, but qemu gui code screws up
<doug16k>
maybe I should try sdl
<doug16k>
it fills each screen with a different coloured checkerboard so you can tell it is really different
<doug16k>
whipped together the printf in there off the top of my head. apparently I have implemented printf too many times :P
<klange>
Hm, how does the vmmouse work with multiple displays...
<doug16k>
I expect each screen to have a coordinate and mouse is one big space
<doug16k>
so if a screen is at 100,100 and mouse is at 150,120 then mouse is 50,20 away from top left of that monitor
<doug16k>
oh I am assuming virtio
<doug16k>
yeah idk
<doug16k>
it must have a display index of some kind in the event
<doug16k>
oh NEAT! in -display sdl it pops up another window for each display I initialize!
<klysm>
and on that note, it would be pretty neat to see qemu demoing a transparent window
<klange>
the gtk interface lets you detach them somewhere for that
<doug16k>
even in SDL, qemu falls over with 8 or more secondary-vga. 7 work fine
<doug16k>
falls over in a bad way where it doesn't error - just screws up and all displays are blank
<doug16k>
feels like an array overrun
<Oli>
As a brief tangent, I want to comment about that I appreciate skyz's computer-related questions; I find myself served by pondering about the why and hows involved.
<doug16k>
I should take that dispi stuff and make a kernel module for dgos so I can do modesetting and multimonitor from inside the kernel, even without efi
<doug16k>
it's vendor 0x1111, device 0x1234, with a comment in bochs that admits they know it is wrong and they hope it doesn't conflict, lol
<nur>
hey guess what I think I got my registers struct to read in my C interrupt handler after passing the regs to it from my assembler wrapper in x86_32
<nur>
I did the whole stack alignment thing _before_ I pushed the struct
<nur>
because uh, doesn't the SP need to point to the last thing we pushed?
<doug16k>
I wonder if the pcisig allocated 1111 to bochs
<doug16k>
nur, no it doesn't need to be aligned before pushing args, it needs to be aligned before the call
<doug16k>
I described the procedure the other day
<nur>
but if you add space to the stack before the call, your SP points to some empty space
<nur>
instead of the args
<doug16k>
you sub $ how_much_i_need,%esp then and $ -16,%esp
<doug16k>
then you mov your args into N(%esp)
<doug16k>
where N is field offset
<doug16k>
then you are aligned and no hard to figure out amounts of adjustment to make it so it ends up aligned by the time it gets to call
<nur>
oh make the space first
<doug16k>
that is how compilers do it
<doug16k>
they make enough for worst case amount of stack args
<nur>
ahhh okay I missed the "make the space first" part.
<doug16k>
then you can do the and -16 to align it
<doug16k>
then you are exactly where you need to be. now just put stuff relative to where esp is by then
<nur>
what is "field offset"
<doug16k>
you have a struct for your context, right?
<nur>
yes
<doug16k>
the field offset is how many bytes distance it is from the start of the struct to that field
<doug16k>
struct f { int a; int b; int c; }; < the offset of c is 8 if int is 4 bytes. offset of a is 0
<nur>
like, struct padding
<nur>
?
<doug16k>
the distance from the beginning of the struct
<nur>
ohh okay gotcha
<doug16k>
each field is some distance from the beginning of the struct
<nur>
right
<doug16k>
you can then work in the order the struct is written, not backwards
<nur>
what is N(%esp)? N times esp?
<doug16k>
you can put the stuff in there in whatever order you please
<doug16k>
it means add N to esp and use that address
<doug16k>
N is a constant number
<nur>
right you want to move the pointer back N to add the args
<doug16k>
if it were a struct of 3 32-bit fields, they'd be at 0(%reg) 4(%reg) 8(%reg)
<doug16k>
if "reg" holds a pointer to where that struct instance is located in address space
<nur>
ah so we'd be using mov instead push
<doug16k>
yes
<nur>
I think my method gets me the same result too, just a different way to go about it. Is there a downside to it?
<nur>
or is it just canonically wrong or something
<doug16k>
slightly more instruction bytes than pushes
<doug16k>
not bad though
<doug16k>
modern cpu will gobble up mov way, could even do slightly better
<nur>
eh it's fine :) as long as it works
<doug16k>
pushes are more work. even if they are heavily optimized, there are usually limits
<nur>
there is another issue though, I can't call my printf in the middle of the interrupt handler, that's what's causing the gpfs
<doug16k>
why can't you
<doug16k>
I can
<nur>
it gpfs and I need to find out why :(
<doug16k>
there is no such thing as "can't call printdbg"
<nur>
well my printf is wrong I guess
<doug16k>
just encouraging you that you can make it completely reentrant and bulletproof and always work
<doug16k>
it's not bound to #GP or anything
<nur>
thanks
<nur>
is osdev always this fun :-|
<doug16k>
osdev can be a fountain of difficult bugs fix if you want it to be :)
<doug16k>
to fix
<nur>
who wants that :)
<nur>
it just happens whether or not I want it
<doug16k>
people with giant debugging muscles :P
<nur>
fun :p
<nur>
osdev: the crossfit of debugging
srjek has quit [Ping timeout: 244 seconds]
<doug16k>
nur, did you fix the issues with ds and es I pointed out?
<doug16k>
and eflags.df
<nur>
wait what
<nur>
what issues
<nur>
I thought I saved them
<doug16k>
<doug16k> user code could screw over that isr with this: xor %eax,%eax ; mov %ax,%ds ; mov %ax,%es ; std ; lol: jmp lol
<nur>
oh frig
<doug16k>
so could kernel code that went into the weeds
<doug16k>
by the time it exceptions hilarious selector load attempts almost occurred
<nur>
wait if user code is allowed to screw with DS
<nur>
how do we stop them
<doug16k>
you don't
<nur>
I mean I saved those registers
<doug16k>
I explained that
<doug16k>
the interrupt entry gets ss from tss, or keeps using current good kernel ss if already in kernel...
<doug16k>
so ss is guaranteed good
<doug16k>
cs is guaranteed good. got it from IDT entry
<doug16k>
everything else, who knows
<nur>
so as long as I save ds and es on the stack I am good right
<doug16k>
so you save them all, but they are still containing potential garbage from code example I gave
<nur>
ahh
<doug16k>
you need to load your kernel data selector into ds and es
<doug16k>
after you push theirs
<nur>
right, right
<doug16k>
all the pushes uses ss automatically
<doug16k>
they work
<nur>
gotcha
<doug16k>
any memory access that uses esp or ebp as base uses ss automatically
<doug16k>
you could override with ds prefix if you needed to
<nur>
and what of eflags
<doug16k>
cld
<nur>
I do cld
<doug16k>
good
<doug16k>
let me make one more suggestion while we are right here
<doug16k>
it is probably worthwhile to check whether ds and es already have the right selector, and if so, don't load ds or es
<doug16k>
it is worse than mispredicting to load ds or es
<nur>
in terms of performance huh
<doug16k>
on modern one I mean
<doug16k>
older one weren't much better
<doug16k>
it does a bunch of validations
<doug16k>
the main issue is how it stalls it
<doug16k>
it can't have half the code in the pipelines using one ds base and half using some other
<doug16k>
it waits for everything to finish
<doug16k>
so very worth checking wehther to do a gigantic mov to ds or es
<doug16k>
imagine a giant footstep thundering down. that is the mov to ds sound effect
<nur>
ouch
<doug16k>
coffee spray instruction
<doug16k>
that is why long mode is better. you can completely ignore ds and es and cs and ss base
<doug16k>
you can laugh at their funny ds and return cleanly
<doug16k>
without fixing it
jaevanko has quit [Quit: Leaving]
<doug16k>
it even puts 0 in ss in cpl0 on interrupt entry because it ignores it and it's better than leaving a weird cs/ss mismatch, that can't happen on x86
<doug16k>
cs and ss must be same privilege
<nur>
do you have to check DS every time you go into kernel mode
<nur>
I suppose interrupts are the only way that happens right
<doug16k>
if it came from user mode, you expect the program to be going berserk at all times, so you must be prepared for crazy ds, es, fs, gs
<doug16k>
you wouldn't believe how much code makes nonsense api calls, ignores the error, and nobody notices
<doug16k>
it might screw up ds somehow and fluke back into a half way reasonable state and use so many things on the stack that it gets away with it for an impressively long time
<doug16k>
totally expect whatever code you preempted to be catastrophically screwing up right then
<doug16k>
this is how exceptions are handled too, isn't it?
<nur>
yeah
<doug16k>
so brace for full impact
<nur>
<doug16k> totally expect whatever code you preempted to be catastrophically screwing up right then <- if I was from Texas I'd have this embroidered onto a throw pillow
<doug16k>
lol
<doug16k>
memory corruption, where you map the same physical page in two places, or actually write out of bounds, can cause it to jump to a nonsense location and start executing weird stuff that could easily end up infinite looping. it will wait any amount of time to be preempted and crash you if you don't handle it
<doug16k>
so instead of looking at the real crash, you see the kernel crashing and no clue why
<doug16k>
who looks at ds? not often
<doug16k>
32 bit code worries about ds, 64 bit doesn't
<doug16k>
it would probably recurse into the handler over and over until the stack pointer destroyed so much stuff that it can't even continue executing the loop. because the stack overwrote the loop, lol
<doug16k>
by then you are diagnosing the aftermath of a nuke
<doug16k>
good luck with root cause
<nur>
wow
KREYREEN has joined #osdev
<doug16k>
I did that
<nur>
it sounded like speaking frome experience :)
<doug16k>
then I added large guard regions around my stacks
<geist>
yah a page is generally enough but if you ahve the aspace...
<doug16k>
it could get a giant miracle rsp adjustment that works well enough and overwrites stuff, but highly unlikely
froggey has quit [Ping timeout: 265 seconds]
KREYREEEN has quit [Ping timeout: 252 seconds]
<nur>
I don't even have pages enabled yet
<doug16k>
then it could go nuts like I described and stack trashes a lot before it triple faults
HeTo has joined #osdev
<doug16k>
just try to make it so that can't happen
<geist>
so the fun thing to do is deal with stack overruns on risc architectures like arm or riscv
<geist>
sit down and try to figure out a scheme: it's surprisingly tricky to do
<geist>
at least efficiently
froggey has joined #osdev
<doug16k>
you could easily end up in an infinite loop on those, right?
<geist>
right
<geist>
so it's a fun thing to figure out: first instruction if your handler you got nothign to work with
<geist>
what do you do? what do you do!
<geist>
like in speed, barrleing down the freeway at 50mph
<doug16k>
yeah, usually the architect thought of that and gave you *something*
<doug16k>
you could just take a register. I guess you try really hard not to do that
<geist>
right, some arches do that: i think mips ABI had a k0/k1 register that is trashed at any time so user space can't touch it
<geist>
and microblaze does too
<geist>
riscv's bone it throws you is there's a SCRATCH register that you can swap a regular one with
<doug16k>
on one hand, it would be sad to allocate a whole register to handle something that is supposed to never occur. on the other hand, there are an excessive number of registers
<geist>
but you kinda need it for user space to, so it's a bit difficult. i dunno
<doug16k>
I mean to take it so you can handle stack overflow
<geist>
right. so for a kernel you can just say 'imma use register foo' and then tell the compiler to leave it alone
<geist>
and baiscally you need smething like that
<doug16k>
if userspace used that register when they aren't supposed to, it could spontaneously get overwritten by the kernel and be zero next time they see it
<doug16k>
I'm picturing it as an emergency storage place for that nasty scenario where stack overflowing and in exception handler entry point
<doug16k>
I can give you a few ways to deduce which cpu you are on x86. isn't there something similar on those?
<doug16k>
even something hideously slow
<geist>
basically you need to per cpu stash something and then do a test which suchs
<doug16k>
can't you reserve a register that doesn't have to hold any particular value, and then just copy sp to that one and check it?
<geist>
you can do that, yes
<geist>
or put the mask of the SP in it perhaps
<doug16k>
and arrange for it to be zeroed on context restore
<geist>
and do some sort of and test again it
<geist>
well, if you're in the kernel you can set it up as soon as you enter it
<geist>
and then give the register back to user space. basically maintain a custom abi in the kernel
<geist>
anyway, it's not undoable, just requires thinking outside the box a bit since the hardware doesn't just do a double falt for you
<doug16k>
on x86 they had to help you - the cpu pushes the interrupt frame whether you like it or not
<doug16k>
not being able to push is a "their" problem, not an "our" problem :P
<doug16k>
it insists
<doug16k>
it insists so hard that they arranged a way to recover when it can't :)
<Mutabah>
geist: Re the RISCV scratch register, it was a mind-job getting the logic around that right
<Mutabah>
Fun, but hard
<geist2>
yeah right?
<Mutabah>
iirc it was swap sscratch with a gpr, save sp into the memory pointed to by (originally) sccratch, load new sp, swap back, and then get to pushing
elastic_dog has quit [Read error: Connection reset by peer]
elastic_dog has joined #osdev
<Mutabah>
(ah, it was a second GPR not SP, so the code has a scratch reg for checking the source of the interrupt)
<bslsk05>
github.com: rust_os/start.S at master · thepowersgang/rust_os · GitHub
elastic_dog has quit [Read error: Connection reset by peer]
elastic_dog has joined #osdev
<doug16k>
going to take a stab at getting my qemu-rom project to start up and work in arm64 vm
<doug16k>
I'd put 1: block after the end, and jmp back to 2b. then it falls straight thru if preempting user
<doug16k>
looks like you had to be careful all the way through that
<doug16k>
I mean line 166 block
elastic_dog has quit [Read error: Connection reset by peer]
<doug16k>
s/to 2b/to line 169/
<Mutabah>
doug16k: Just for the marginal improvement of fewer jumps on the user path?
iorem has quit [Quit: Connection closed]
<doug16k>
it will probably mispredict that j 2f on out of order ones
elastic_dog has joined #osdev
iorem has joined #osdev
<doug16k>
this occurs a ridiculous number of times
<doug16k>
it's not like it's run-once or something
<Mutabah>
Hmm... seems reasonable
* Mutabah
attempts to remember for non-work times
<doug16k>
also I prefer .Lactual_words labels over 2b 1f
<doug16k>
if you don't mind unsolicited code review feedback :D
<Mutabah>
Go ahead
<Mutabah>
I hadn't considered the unconditional branch cost on OOO
<doug16k>
yeah even unconditional will need an entry in the prediction structures
<doug16k>
they have to fetch large blocks of instructions, it can't nitpick each one
<doug16k>
it needs a cheat to know after that giant fetch block, goto there
<Arsen>
oh, skyz was here, took less to get banned than I expected. we were dealing him on discord for a while, he never said something like this, but that's probably because he couldn't fit it in next to plan9 and 9P and skynet
<moon-child>
also means you have junk in your cache that you're not actually executing
<doug16k>
when cpu is doing work you will find it is almost always in user mode. when the machine is idling, you are preempting your halt, those are in kernel. so you arrange it so it is more efficient when doing work, and not as good when idling
<doug16k>
typo line 165
<Mutabah>
yep, spotted that earlier
<doug16k>
helping the predictor be correct is how you make modern cpus go fast
<doug16k>
it has the alu stuff down pat
<doug16k>
if you can keep it deeply speculating ahead it helps a lot
<doug16k>
make it not start over whenever possible
sprock has quit [Ping timeout: 245 seconds]
sprock has joined #osdev
<doug16k>
when you make a custom configure, what's the trick to make `make` rerun configure when the configure script changes and stop using this makefile?
<doug16k>
does make watch out for the makefile being replaced and make it just work?
<doug16k>
what if you didn't change the makefile, and only updated a generated makefile include
<doug16k>
does make go as far as watching all the included files for changes?
<moon-child>
idk if exec works that way in a makefile
<doug16k>
I mean homebrew configure
<doug16k>
script that generates CC=g++ ... ARCH=whatever file and you include that in the main makefile
<doug16k>
lol, I mean CXX
<moon-child>
then I guess just, makefile: configure\n./configure; exec $(MAKE)? I don't see why that would be different
<doug16k>
oh I see what you meant
<doug16k>
I misunderstood at first, sorry
<moon-child>
:)
DeepComa has joined #osdev
DeepComa has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<klange>
Okay I spun up multiple displays and I see no viable indicator of what screen the cursor is on... I tried setting offsets, I checked all the data bytes from the backdoor, there's nothing here.
<doug16k>
they are all 0,0 at top left?
<doug16k>
in the mouse events
<klange>
0,0 at the top left, 0xFFFF,0xFFFF at the bottom right, now difference in flag word, no extra data in the upper half of either coordinate register.
<klange>
no*
<doug16k>
secondary-vga or virtio multihead?
<doug16k>
are they bochs dispi framebuffers?
<klange>
secondary-vga, both are bochs dispi
<doug16k>
what -display?
<klange>
gtk
<doug16k>
could be broken in one and ok on other
<doug16k>
I'd try sdl
<klange>
or it could just not do anything; oh there are two more registers I can check
<doug16k>
yeah it could be a design bug that is still there because secondary framebuffer is probably not a common thing
<klange>
I don't... see anything in qemu_add_mouse_event_handler that even suggests they're doing anything with different displays
<klange>
You get an x, y, dz, buttons... I guess they could map x/y to something better than the the 0-0xFFFF ranges, but they don't appear to.
<doug16k>
I mentioned the segfault with 8 secondary-vga in #qemu. crickets
Oli has quit [Ping timeout: 272 seconds]
<doug16k>
I felt like I was complaining to a helicopter manufacturer about what happens when you land upside down
<klange>
okay yeah ubuntu with legit vmmouse drivers from VMware does exactly what I do, so this just doesn't support multiple displays.
<klange>
Ubuntu doesn't even see the other display once I'm in Gnome, though Plymouth rendered to both.
<klange>
Hm, but what does usbtablet do~
<doug16k>
probably something good. that's what a production OS would do
<klange>
maybe, but at the same time most actual tablets are also their one single monitor, so...
<bslsk05>
github.com: qemu/multiseat.txt at master · qemu/qemu · GitHub
<klange>
Looks like you can map usb-tablet or virtio-tablet-pci to the individual displays
<doug16k>
nice!
<doug16k>
kind of easier for you - no trouble figuring out which monitor it means
_whitelogger has joined #osdev
<doug16k>
does qemu do any I/O hole memory remapping stuff?
<doug16k>
or does it just blat out RAM from zero to whatever and make I/O shadow it?
<doug16k>
BARs I mean
<doug16k>
and RAM under the BIOS ROM is lost
<doug16k>
and under the MMIOs
<doug16k>
in my bios I just slap everything right before 0xe0000000, and don't really worry how far down it maps BARs
<doug16k>
and for I/O I slap everything at 0xe000 down, same idea
<doug16k>
that should work?
<doug16k>
hey I could make a program and TIAS
<doug16k>
just keep moving a BAR down and see if I can get it all the way down to zero even
<doug16k>
and still work
<doug16k>
and how high would work?
<doug16k>
all the way to crazy 52 bit probably
<doug16k>
why not?
<doug16k>
at least 48
<doug16k>
my real cpu is 48 virt, 48 phys
<klange>
okay the vmmouse is hooked up to 'input-legacy' which discards all data about the source display, so even if I wanted to squeeze that information into the upper word of the button register it would be a rough patch
<klange>
guess I have to implement the virtio stuff...
<klange>
or a usb stack... or both...
<doug16k>
virtio is good because you reuse it for other things
<doug16k>
it's really easy to make virtio drivers once base is done
<klange>
usb is good is because real hardware :|
<doug16k>
yes
<doug16k>
my last comment applies to usb too. once you have the HC working, class drivers are a pleasure to write
<doug16k>
same reason virtio is good. all you need is pipes you can send to and pipes you can receive from
gareppa has joined #osdev
tenshi has joined #osdev
gareppa has quit [Remote host closed the connection]
<doug16k>
virtqueue in virtio, endpoint context in usb
<klange>
virtualbox... does not have the mmio interface to the bochs display, annoyingly; no idea how multiple displays work there
<doug16k>
usb ones are one way, except 0th one, which does special request response sequences
<doug16k>
you access it as if it were a genuine ibm vga card?
<doug16k>
or does it emulate some super vga that is half decent?
<klange>
it does have the port i/o interface
<doug16k>
you can go into massive 32bpp modes though right?
<doug16k>
or do you get VBE to do it and not sure exactly what happens?
<klange>
yeah, it claims to be a fine VBE_DISPI thing but it only does the 0x01CE/0x01CF interface
<doug16k>
ah
sortie has joined #osdev
<klange>
need to reconfigure my video stuff to make objects for multiple display devices and present each as /dev/fb{n}
<klange>
and then I can hack in some dumb rendering stuff for the compositor so it can span them like they're next to each other
<sortie>
klange. Sitting in front of a multiscreen toaru setup. Hacker.
<kazinsal>
yeah looking at the vbox open source edition it seems that there's only an MMIO PCI region if you have it set up as "VBOX_WITH_VMSVGA" which appears to shove some VMware SVGA bits into the VBox BGA
<klange>
QEMU I've been able to actually set up and get multiple framebuffers on, esp. thanks to doug today, so I'll get stuff working nicely there and then figure out how vbox and vmware do it
<Mutabah>
hey klange, now that you've done a x86-64 port, want to do a riscv one? :D
<klange>
vbox gave me a menu option when I asked for two monitors, and I think I even got a host-guest message when I asked to enable the second one, but dunno where to frob bits for it with one IO port interface
<klange>
Mutabah: I was kinda thinking I'd do an arm port first, but it's totally on the table and misaka should be much more portable
<klange>
exciting times for a certain OS
<klange>
just imagine what the feature list will look like on the next PonyOS after all of this :D
junon has quit [Ping timeout: 252 seconds]
<klange>
Fix SMP bugs → Finish new network stack / Sockets API → USB → aarch64? → riscv64? → take over world
junon has joined #osdev
<sortie>
Toaru webassembly
<klange>
already have the kuroko build ready
<klange>
Mutabah: if I wanted to pursue a riscv64 port, what would you recommend for a test setup? I'm way outdated on the state of emulation for it, especially re: devices
<klange>
i know of... qemu obviously, and tinyemu? and I think I recall tinyemu has a framebuffer of some variety?
<Mutabah>
I used qemu with virtio devices
<froggey>
^ same for my arm64 port
alexander has joined #osdev
MarchHare has quit [Ping timeout: 244 seconds]
<klange>
Let's see... I have a handful of things that can probably be moved up to 'generic', like the bitmap allocator, kernel heap manager... maybe the PS/2 drivers but if I'm going to target a virtio machine for either of those platforms who cares...
<klange>
I need to split up the video drivers, especially given two are done with port i/o stuff, but the qemu one should work with anything that does mmio pci...
<klange>
I really did manage to make the process layer architecture agnostic, after much work. Though I do need to move the __seg_gs stuff behind a little macro...
<Mutabah>
For ARM, the PL011 exists... but not sure how common it is in practice
<klange>
Yeah, like, I'm aware of the existence of PS/2 controllers for other platforms, but... _really_?
sortie has quit [Ping timeout: 245 seconds]
<klange>
I think the dodgiest thing that's still super x86-64-tied is the irq infrastructure as I kinda just gave up and plopped in the legacy PIC stuff; there's no generic "interrupt" interface yet.
<Mutabah>
Yeah... you're going to need to change that
<Mutabah>
that was the largest pain point I had with riscv/arm64
<klange>
But... system call management, the whole VFS, the procfs [is kind of cheating with a couple of #ifdef __x86_64__s]... userspace apps should be fully generic now, libraries are 95% there - but the graphics lib has some baked in sse/mmx.
<Belxjander>
klange: hrmmm....biggest pain point I saw for the updated AmigaOS on PPC replacing 680x0 series processors was the actual device drivers... as for Interrupt and other "special features" of the kernel... being a micro-kernel once the kernel itself was done everything else mostly was recompilation... the graphics librar
<Belxjander>
y got some attention for arbitrary graphics drivers replacing the original OCS/ECS/AGA chipset support but that already has precedent support from 68K graphics card RTG drivers
<Belxjander>
the only "pain" for backwards compatability is actually the need to run "Chip Emulation" programs for specific 68K compatability support... otherwise anything that skips hardware and uses the OS mostly works...
<Belxjander>
anything that touches hardware needs to be updated
<Belxjander>
klange: so for Interrupt Handling... do you have any concept for how to "black box" it all in a usable way?
<geist>
doug16k: you were piddling with this i think. if you run qemu with OVMF UEFI -bios, what vector to the UEFI app does -initrd show up?
<geist>
ie, is it a secondary image somewhere, or referenced in acpi or something?
<Belxjander>
or is it all still "not yet a red box" with regards to needing hardware knowledge to tap the right Interrupt ?
<geist>
ie, how can the uefi app 'see' the initrd contents
pretty_dumm_guy has joined #osdev
<klange>
geist: ... ooh, does it even show up at all? I know the -kernel and -initrd options are very loose and machine-dependent, but I was under the impression they generally bypased the -bios?
<klange>
but then... okay I should have known better because I've literally been staring at a screen that says "SeaBIOS" for several minutes over the past few weeks as my initrd loads.
<geist>
-kernel is intresting (at least on ARM). whaever you put in -kernel if it's a PE binary it just runs it directly
<geist>
skips the whole 'go find it on the disk' phase
<doug16k>
geist, should be fw_cfg
<klange>
x86 of course has the linux boot protocol implementation and multiboot1
<Belxjander>
geist: s that an OVMF launch thing?
<geist>
Belxjander: probably?
<geist>
doug16k: well if so that's super lame, because you have to 'detect' that you're on qemu
<geist>
i was *hoping* there was some in-uefi solution
<doug16k>
ah yeah that chicken and egg thing
<geist>
like it shows up as an alternate image or soemthing
<Belxjander>
for OVMF initial ramdisks... are they GPT partitioned ?? or MS-DOS basic partitioned? or just a raw filesystem?
<doug16k>
should be raw binary
<geist>
basically i have a PE based bootloader that has the usual logic of grubbing around for the BSP and/or boot partitinos
<geist>
but if you load it as -bios OVMF -kernel bootloader it'll just start directly
<geist>
(at least on arm)
* Belxjander
has one HDD with each partition header type and looking at the GPT headers... it appears the same as the basic partition scheme followed by a binary that binds to the UEFI as another .EXE to run at startup... so... does that hint at anything for ramdisks?
<geist>
my guess is the -initrd on arm is loaded and pointed to by the device tree
<geist>
which have to figure out how to find in the uefi environment
<geist>
note building a disk image with a BSP and putting the bootloader there does the Right Thing
<geist>
it's just nice if you can skip that and still be a semi-functional thing
sortie has joined #osdev
<doug16k>
geist, should be in the "systab" somewhere
<doug16k>
that is where it tells you acpi - makes sense for device tree to be there
<doug16k>
it's analogous
chartreuse has quit [Ping timeout: 264 seconds]
<doug16k>
systab is in x14 in your efi startup code, according to my initial arm port implementation
<doug16k>
klange, on my distro it is called qemu-efi-aarch64
<klange>
Do we have an aarch64 barebones...
<doug16k>
did you mean aarch64 or am I confused?
<klange>
Hm? In response to what?
<doug16k>
the efi rom for it
<klange>
`/usr/share/AAVMF/AAVMF_CODE.fd` is listed as the firmware in `/usrs/hare/qemu/firmware/60-edk2-aarch64.json`
<klange>
With the description "UEFI firmware for aarch64"
<klange>
This is Ubuntu 20.04, which is about two years stale on QEMUs, though.
<doug16k>
there are a few for different machines I think
<doug16k>
different -machine
<doug16k>
little tip: use -cpu max
<doug16k>
I spent a lot of time troubleshooting when it was that
<doug16k>
I was trying to get efi to boot in qemu and I had it all along, with -cpu that couldn't execute it
<doug16k>
Belxjander, it's actually not hard to get ovmf to build from source
<doug16k>
once you do the weird steps it all works
<doug16k>
from linux anyway. can't say what happens on windows or anything else
<doug16k>
seems like it would work there too though
<Belxjander>
doug16k: using AmigaOS I would need to start with getting a working developer toolchain built... and that in itself also begs the question of whether the toolchain for cross-compilation is actually broken or not ;)
<doug16k>
ah I thought it might be that hard :P
* Belxjander
has not actually ever had a working cross-compiler built from source...
<doug16k>
you only need a compiler good enough to compile a better compiler
<doug16k>
might be able to bootstrap out like that
<j`ey>
Belxjander: run a vm w/ linux :P
<doug16k>
yeah, set up a vm and cross compile
<j`ey>
inb4 no VMs on Amiga
<doug16k>
you don't have another machine though?
<Belxjander>
nope
<doug16k>
just to escape having an old compiler
<j`ey>
dual boot? :P
<Belxjander>
j`ey: still PowerPC based and I need to sort that out... need to find a non-debain broken installable kernel to work with
<doug16k>
use bochs and figure out how to live forever so you can wait for it to boot linux?
<Belxjander>
along with a rootfs base filesystem package set I can actually work with that wont break if I want things removed
<doug16k>
you will have lots of time to figure out how to live forever while you wait for bochs to boot linux
* Belxjander
can still recall a debian system that self-stripped everything executable for programs and libraries once a single dependency was force removed...
<Belxjander>
doug16k: more wanting to get the OVMF images so I can get working on writing my own Virtual Machine, preferably then later to sort out some partial system simulation material to plug in to it
<j`ey>
what do you mean by 'writing my own Virtual Machine'?
<j`ey>
as in an emulator?
<Belxjander>
something like a more generic support library with plugin cpu modules
<z_is_stimky>
swappable components vm
<z_is_stimky>
sounds neat
<Belxjander>
anyway... catch you all tomorrow... since I have a day off tomorrow
<Belxjander>
z_is_stimky: kinda neat... kinda a headache at this point...
<Belxjander>
need to sort out a generic virtualized memory model that works on top of the host memory management
<Belxjander>
more implimentation specifics than anything else
<doug16k>
is it 68k cpu?
<doug16k>
newer isn't it?
<doug16k>
ah powerpc
<doug16k>
I want to offer a beefy vm on my 2700x and ssh access to Belxjander because it's such a worthy cause to get a better compiler working :D
<doug16k>
I'm going to see what happens when I tell gcc-mirror to cross compile an amigaos-powerpc gcc 11.1.0
GeDaMo has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
pretty_dumm_guy has joined #osdev
Arthuria has joined #osdev
<doug16k>
ah I probably have to build a linux-gnu gcc targetting amigaos-powerpc then use that crosscompiler to cross build it
<doug16k>
wait
<doug16k>
yeah I guess just the linux gnu one from my package manager is good
<doug16k>
I am not accustomed to worrying about the os part of triple :D
dormito has quit [Ping timeout: 245 seconds]
<klange>
Well, I think I at least got this stable enough that it can generally get to a GUI, run multiple `plasma`s, fiddle with a terminal, confirm it's actually running multiple things in true parallel, and it doesn't seem to be crashing
<klange>
There's still plenty of gaps in the armor, so to speak - plenty of places in the VFS particularly that are in need of much better synchronization, known issues with process startup/teardown races...
<klange>
But it's "usable enough for demonstration purposes".
<klange>
I'm going to let this sit on my thinkpad for a while and see if it can churn through window manager messages and redraws for an extended period
<klange>
that should demonstrate at least most of the ongoing stuff is stable... I can write up some stress tests for process creation and destruction later to run in qemu.
<Mutabah>
I guess you can PM them and tell them of the oopsie?
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
pretty_dumm_guy has joined #osdev
alexander has quit [Ping timeout: 268 seconds]
isaacwoods has joined #osdev
elastic_dog has quit [Read error: Connection reset by peer]
elastic_dog has joined #osdev
<klange>
oh right I have a classic PS/2 synaptics-compatible touchpad on this thing... that has a funny little PS/2 communication method were you pack bits into resolution commands (because _everything_ that extends mouse functionality on PS/2 uses resolution commands, of course)
alexander has joined #osdev
f4t4l_3rr0r has joined #osdev
IRCMonkey has quit [Ping timeout: 244 seconds]
<FireFly>
oh dear
f4t4l_3rr0r is now known as IRCMonkey
<klange>
would be nice to have that fancy two-finger scrolling
mctpyt has quit [Ping timeout: 268 seconds]
mctpyt has joined #osdev
IRCMonkey has quit [Quit: .oO (bbl tc folks~!)]
angelsl has quit [Ping timeout: 272 seconds]
angelsl has joined #osdev
Oli has joined #osdev
ahalaney has joined #osdev
Oli has quit [Quit: leaving]
isaacwoods has quit [Quit: WeeChat 3.1]
Oli has joined #osdev
handicraftsman has left #osdev [Leaving]
SwitchOnFreenode has quit [Remote host closed the connection]
CompanionCube has quit [Excess Flood]
Vercas has quit [Quit: Ping timeout (120 seconds)]
SwitchOnFreenode has joined #osdev
Vercas has joined #osdev
gog has quit [Quit: bye]
gog has joined #osdev
* gog
meows
qookie has joined #osdev
<gog>
weeeeeeeeeeeeeeeeeeeee i keep looking at my bootloader and cringing and getting nothing else done
<j`ey>
gog: ignor ethe bootloader
<j`ey>
start on the OS!
<gog>
i do have a start!
<j`ey>
have you got any kinda proceses?
<gog>
heh
<gog>
in theory
<gog>
(that means no)
<j`ey>
work on that ^:)
<gog>
i can handle page faults tho
<gog>
it's all very fragile tho lol
<j`ey>
that's ok, you can tighten it up as you find the bugs :-)
transistor has joined #osdev
srjek has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
<Oli>
My operative development project so far has consisted in putting all my focus on figuring out my ideal design and implementation of, for a first and second stage bootloader.
<j`ey>
this is why I used qemu's -kernel, no need for a bootloader
<Oli>
Jumping around documentation, articles and theory about operative systems doesn't count on the project for me, as I totally haven't written a single line of code by. I didn't though about calling the kernel directly on QEMU: I was too focused on how to get it up on real hardware in a boot manager to test it more flexibly on. Thank you for bringing up about, j`ey! I think that I already benefit from giving
<Oli>
at least a crude operative system kernel implementation a try.
<j`ey>
btw it's operating, not operative
<j`ey>
I'm more interested in the concepts and general ideas than 'oh it has to run on some real hardware'
<Oli>
Thank you for pointing that out: It flew over my head it was spelled differently in English, by getting used at that in Spanish it is always called "operative", as "sistema operativo"
<j`ey>
everyone can understand anyway :)
<GeDaMo>
I'm not bothered about running on real hardware either, I'm more interested in a virtual machine based system
eau has quit [Quit: bleh!]
eau has joined #osdev
<Oli>
I am most driven to develop a operating system for totally knowing it's innerworking, how it interacts with hardware, and yielding full usage control of a system's computing power.
vdamewood has joined #osdev
<Oli>
I also think that it can greatly benefit me in writing audiovisual baremetal programs for other systems, which I feel most passion for, in regards to computers.
<j`ey>
you mean demoscenes?
KidBeta has quit [Ping timeout: 264 seconds]
MarchHare has joined #osdev
<Oli>
Yes! I recall myself feeling deep attraction and wonder about the Amiga-style cracktros for PlayStation 1 games I watched at, as a child; it holds the biggest part of where programming is in my heart. The first cracktro I recall seeing on, was the displayed in the video on the web page this hyperlink leads at: https://www.youtube.com/watch?v=99TU_2R6qxA
<bslsk05>
'FFIX Spanish Crack by PARADOX (her-8.mod, by estrayk)' by Darkkjoul (00:05:37)
<j`ey>
lol the 8bit tunes :)
acheam has joined #osdev
MarcinWieczorek has quit [Remote host closed the connection]
<nur>
okay uh how do I get gdb to step through my asm interrupt handler
<nur>
it gets a little confused when an interrupt is called
<nur>
says it doesn't know where the function ends
<Geertiebear>
if you need an easy bootloader why not use limine :)
acheam has joined #osdev
CompanionCube has joined #osdev
mahmutov has joined #osdev
amanita_ has quit [Quit: Lost terminal]
mahmutov has quit [Ping timeout: 245 seconds]
<Oli>
I just looked up limine; it looks good for what I have seen of so far. I however intend to write all in the project myself, and it only doing what I want it to. I am currently aiming to wrap up a one-stage bootloader to a currently imaginary kernel, and getting to feel comfortable using gdb to know what I want to about the state of the machine.
mahmutov has joined #osdev
<Oli>
nur, do you have symbols for your Assembly program loaded in gdb? One may, with the next gdb command: symbol-file -o 0x<memory offset in hex> <filename>.sym
<Oli>
Symbols may be generated, if using GNU's assembler, by passing the -g parameter to as
<doug16k>
or -Wa,-g if compiling the assembly with gcc
srjek has joined #osdev
<geist>
nur: also there's a way to mark the end of functions in asm. you dont have to do it, but otherwise the function symbol has no length
<geist>
and might make the debugger unhappy, like it appears to be doin
<geist>
i always put itin a macro like FUNCTION(name) ... END_FUNCTION(name)
<geist>
well at least on gas. i dunno abot nasm
<clever>
could the `FUNCTION(name)` macro also do function-sections behavior?
<geist>
possibly. you'd need to set an section attribute that matches whatever logic the compiler does
<geist>
not sure it'd properly track all external references in the linker
<clever>
yeah, it would basically be `".section .text." + name` in an asm macro
<geist>
and i dunno what it'd do with intra-function references within the same file. maybe if the assembler sees that they're separate sections it can't use local branches or whatnot like it probably can otherwise
<clever>
depends on what relocations get emitted
<geist>
right
<clever>
objdump -dr can reveal those i believe
<geist>
if the GC stuff is purely relocation based, which i sspect it is, it should work fine
<geist>
i'd be worried if the assembler generates a direct branch between functions, which i know it generally does
<clever>
my main thought for that, is that i sometimes have random util functions in a .S, which i may not use
<clever>
so i want to gc them
<geist>
but if it sees they're in separate sections maybe it cuts off that logic
<clever>
and those are mostly leaf functions
* geist
nods
<clever>
something to play with, next time i'm in a .S file
<geist>
also iic there's push/pop sections in gas? so you might want to instead of setting the section, push the old one and set it
<geist>
and then in END_FUNCTION() pop it
<clever>
for arm, END_FUNCTION could also toss in a .ltorg
alexander has quit [Ping timeout: 272 seconds]
<geist>
yah not a bad idea
<geist>
actually almost mandatory now that you think abot it
<geist>
you'd want to .ltorg within the same section so it gets hoovered up with the linker
<clever>
only if the .S file is beyond the reach of pc-relative?
<clever>
ah yeah
<clever>
prior to discovering .ltorg, all of my literals wound up in .text
<clever>
so i think it defaults to whatever section is at the end of the .S file
<geist>
thats generally where they go
<geist>
ah yeah
<clever>
my initial fix, was a dangling `literals:` at the end of the file, labeling "nothing"
<geist>
note that big and newer arms dont do that anymore. that was kinda a temporary blip in the development of arm
<geist>
except that it's heavily leaned on in cortex-m
<clever>
just to remind myself, when garbage came up in objdump
<geist>
but yeah you're generally *supposed* to put the literals in .text
<clever>
most of my work has been on arm32, so i'm probably in the middle of that blip?
<geist>
i think the C compiler will generally ltorg after every function, etc
<clever>
i have noticed that the official VPU compiler does that as well
<clever>
most functions are followed by string literals
<geist>
yah though armv7 added more powerful ways to get constants into registers (movw/movt) and then basically deprecated the old mechanism
<geist>
though thumb... etc
<clever>
maybe the exceptions are due to a missing const on a global var?, or being global means it just goes in .rodata
<geist>
i have no idea what this exceptions is
<clever>
and i'm also guessing blindly, because i lack both the source and compiler
<clever>
i'm just guessing, based on the final binary
<geist>
anyway, to complete the thought: more modern OOO arches and whatnot dont do the 'mix the data in the text segment' stuff
<geist>
since it has negative interactions with caches and whatnot
<geist>
plus you have a load/store delay, etc
<graphitemaster>
You know you can also just use call frame information, even inside an interrupt handler, gdb can deal with .cfi_startproc simple and .cfi_endproc, to setup the entries in .eh_frame, doesn't need to be used for unwinding.
<geist>
well a load in this case
<clever>
i also heard about having .text as execute only
<clever>
so literals CANT be in .text
<geist>
right
<clever>
graphitemaster: maybe i should look into that, along with backtrace generation, for getting better errors out of my fatal exceptions
<clever>
graphitemaster: can the debug info be trivially included in the LOAD'd sections? or is it better to post-process something like a coredump after the fact?
<clever>
(baremetal)
<graphitemaster>
When I did some kernel work last I skipped the whole symbol export bullshit that all these projects used and just relied on .eh_frame section for start and end addresses of all functions, even assembly ones
<graphitemaster>
Then my loader just used those
<graphitemaster>
No need to export things anymore, all kernel symbols accessible all the time
<graphitemaster>
And yeah, stack traces made pretty.
<clever>
in my case, i want to remain compatible with a closed-source loader
<graphitemaster>
Yeah you can load it from the kernel ELF
<graphitemaster>
It's just a section
<graphitemaster>
Do it inside kmain or something
<clever>
it basically just shoves the LOAD sections into ram, at the defined addr, and launches
<graphitemaster>
The bootloader won't load them
<clever>
the .elf file will be lost by the time _start has ran
<clever>
so the kernel would have to re-read itself
<graphitemaster>
Yeah
<clever>
and i dont have usb-host support yet, so thats not always an option
<graphitemaster>
Ther elf header is PT_LOAD though, so you can just search for .eh_frame section there, then re-load the kernel image but at the eh_frame section
<graphitemaster>
I imagine you can just mark the section PT_LOAD tbh
<graphitemaster>
With a linker script
<clever>
and then i can also generate symbols to mark the start/end of the .eh_frame
<clever>
and discover where the linker+bootloader left it
<graphitemaster>
Don't need that, eh_frame_hdr marks the start
<graphitemaster>
And the hdr contains the size of the whole section
<graphitemaster>
The header actually contains the whhole binary search table to find any symbol actually
<bslsk05>
github.com: dgos/except_asm.S at master · doug65536/dgos · GitHub
<NieDzejkob>
In what situations can unallocated user stack memory be overwritten? There's only signals, right?
<doug16k>
by "unallocated", you mean below the stack pointer?
<NieDzejkob>
yeah
<doug16k>
there might be a red zone, depending on which cpu
<moon-child>
NieDzejkob: well, the signal is allocataing it, no? :)
<moon-child>
*allocating
<NieDzejkob>
yeah, but from the perspective of the code that's running when the signal hits, it's clobbered
<doug16k>
what cpu?
<doug16k>
what you do with the stack depends
<doug16k>
what you modify below stack pointer or not depends
<doug16k>
sometimes you need to avoid touching their red zone
<doug16k>
if you are the signal injecting code
<clever>
doug16k: ah, so i need to tell gcc that i want cfi at runtime, then it will move from the debug info to the eh_frame
<doug16k>
sometimes you absolutely cannot have a red zone because the cpu can spontaneously and unconditionally push a value to it
<NieDzejkob>
what cpu would that be?
<doug16k>
clever, no. it will put what it needs at runtime in eh_frame. if you convince it you don't do runtime unwinds, you can make it all go into .debug_frame
<clever>
but i do want runtime unwinds, so i can generate a stack trace when things explode
<doug16k>
then you need eh_frame
<clever>
yeah
<doug16k>
you mean the code unwinds itself?
<doug16k>
or you unwind from gdb connection?
<clever>
no gdb involved
<doug16k>
ok
<clever>
upon a fatal exception, it should walk its own stack, pretty-print what it can, and die
<Bitweasil>
clever, have you ever seen Over the Hedge?
<clever>
Bitweasil: the movie? yes
<Bitweasil>
I'm thinking of Shatner's possem's death scene here...
<NieDzejkob>
I'm actually seeking situations where the CPU (with an architecture of my choice) can overwrite memory below the userspace stack
<bslsk05>
github.com: lk-overlay/intc.c at master · librerpi/lk-overlay · GitHub
<Bitweasil>
"Dying... must... walk... stack... the function pointers, I see the function pointers... oh... wait, another function... oh, cruel world, why hast thou been so cruel... " and on and on.
<clever>
that runs a giant printf, to print every register
<bslsk05>
github.com: dgos/entry.S at master · doug65536/dgos · GitHub
<clever>
i see that its calling a libgcc function, to pass it 2 symbols, but how does register_eh_frame then get called, and where are those symbols coming from?
Oli has joined #osdev
<doug16k>
just call register_eh_frame sometime before the first time you try to unwind or throw
<bslsk05>
github.com: lk-overlay/interrupt.S at master · librerpi/lk-overlay · GitHub
<clever>
doug16k: i likely also have to write some CFI info for these
<doug16k>
yes
<doug16k>
if it looks very much like a normal call, it could fluke into working on some architectures
<clever>
exception handlers will save lr, r0-r5, r6-r15, r16-r23, then run a C function with that whole block of state in r0
<doug16k>
with minimal cfi I mean
<clever>
irq handlers will save the same registers, and call a c function with r0 pointing to the saved state, and r1 to something (i forget)
<clever>
and then restore it all upon return
<doug16k>
you probably do want the full detail like my context save stuff so when you go up frames in gdb it actually puts it back to the interrupted context and register variables are right
<clever>
i have no idea how to properly enter-exit irq state, and gdb doesnt support the arch yet
<clever>
so its more about self-reporting upon death
<doug16k>
ah ok
<clever>
upon entering an irq state, the SP may alias to another reg (irq stack), based on other flags
<doug16k>
you need to restore enough for the trace to keep going though
<clever>
the irq enable flag (in SR) is cleared, and the PC+SR get auto-saved to the new stack
<doug16k>
if the interrupted code had caller's frame pointer in an odd place it won't restore it without fully detailed ISR entry code
<clever>
rti will pop PC+SR, restoring the old irq-enable status, and returning control
<clever>
and un-alias the SP
<clever>
there are also software exceptions (like the int opcode on x86)
<doug16k>
the interrupted code might have anything in any weird place. it might have a CFI that says "I have caller's frame pointer (weirdly) in r5" and it'd be fine, it'd use r5 to unwind that reg back. if your ISR code didn't care about r5 then it can't unwind it
<doug16k>
so it will put a nonsense frame pointer in, and your stack trace becomes nonsense
<clever>
yeah
<clever>
currently i'm on the side of caution, save every single bit of state to the stack
<clever>
so irq-entry is more costly, but safer
<clever>
in theory, i could only save what the calling convention says is clobbered, and let the C prologue save the rest
<doug16k>
for functions, absolutely, you only have cfi that says how to unwind preserved (callee saved) stuff
<doug16k>
for preemption like signals or interrupts or exceptions, you need everything
<doug16k>
they might have something important in a crap register right then
<clever>
in which register?
<doug16k>
2ns from now it will go back to normal
<doug16k>
any register
<doug16k>
example: x86_64 syscall. the return address is in rcx for a couple of ns
<doug16k>
not on the stack, at all
<clever>
r0-r6 are assumed to be clobbered by normal function calls, so i save/restore those directly in the irq handler
<doug16k>
rcx is crap register right?
<doug16k>
but if you preempted that then you would need to know interrupted code ecx to get back
<clever>
r7+, are all assumed to be saved/restored by the prologue, so whatever the irq handler runs (compiled c code), will restore those as part of its normal function
<doug16k>
no they aren't
<doug16k>
none of that matters
<doug16k>
all registers are everything in unwind
<doug16k>
any register can be anything
<clever>
i was thinking more from a cost of irq viewpoint, rather then unwind
<clever>
could the irq code save fewer regs?
<doug16k>
irq code can't unless it did a cheese thing like knowing it preempted idle thread's halt
<clever>
i'm thinking along the viewpoint of the calling convention
<doug16k>
that's cheese because who cares about speed when halting
<clever>
r0-r6 are clobbered, so the asm at the vector point must save/restore those, to not clobber them
<clever>
r7+ are saved by the prologue, so the C code ran by the irq, will either save/restore, or not touch them
<clever>
so when returning from the irq (in a non-fatal case), all of the regs are back to the original value
<doug16k>
you aren't talking about the unwind
<clever>
yeah, changed subject there
Arthuria has quit [Ping timeout: 272 seconds]
<doug16k>
if you know for sure you aren't going to context switch, yes, you can assume the handler will preserve the callee saved registers
<clever>
*looks*
<clever>
the context switch function, does a full register push, swaps SP, and then pops it all again
<doug16k>
well you can always assume it
<clever>
so even if i am going to context switch, thats doing its own state save
<doug16k>
yes on preemptive context switch you need it all, if they volunteered, you can save just callee saved regs
<clever>
yeah
<doug16k>
interesting example is my syscall entry code. it saves nothing because the caller is expecting the usual registers clobbered, and the `long sys_whatever()` syscall handler code saves the ones that need to be preserved
<doug16k>
technically it saves how to get back to their stack
<doug16k>
and return address
<clever>
makes sense, and i could do the same for swi
<clever>
the VPU has a user/kernel mode, but i think the official firmware treats it more like non-secure/secure modes
<clever>
while in "user" mode, it can still do most mmio (probably an option), but security related things (DRM) are restricted
<clever>
you must use a specially tagged swi to enter secure mode, and be able to do that
Oli has quit [Quit: leaving]
<clever>
doug16k: there is also some sandbox registers, which i think can restrict what ranges you can issue a load/store to, while in user mode
<clever>
so mmio could also be disabled, and make a functioning userland
vdamewood has quit [Changing host]
vdamewood has joined #osdev
Oli has joined #osdev
<Oli>
I feel curious: Why BIOS' interrupt vector function used to change text background color to blue in real mode, accessed as ax=0b00 bx=0001 int 0x10, in video mode 0, makes the text background display blue on QEMU as expected, but only display a blue horizontal line at the bottom of the screen, with the width of, booting the same program in my computer via UEFI's CSM?
crm has quit [Read error: Connection reset by peer]
qookie has quit [Ping timeout: 272 seconds]
doug16k has quit [Remote host closed the connection]
doug16k has joined #osdev
lg has joined #osdev
Oli has quit [Quit: leaving]
Oli has joined #osdev
lg has quit [Quit: leaving]
mctpyt has quit [Ping timeout: 272 seconds]
<Oli>
FreeDOS' v1.3 RC4 floppy disk displays a menu with a blue background on. Let's see how it does!