channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=21&m=11&d=12
00:05:00 <junon> anyone know the typical config/env var name for specifying the linker? (ld)
00:05:00 <junon> e.g. CC is for c compiler, CXX is for c++ compiler. Which one specifies `ld` typically?
00:05:00 <junon> LINK? LINKER? LD?
00:05:00 <Mutabah> LD is what I use
00:05:00 <junon> okay
00:06:00 <junon> my only reservation about that name is due to MSVC's link.exe but I think it's fine in this case.
00:07:00 <moon-child> I usually use 'LD' to point to the 'ld' binary, but CCLD' for the c compiler when it is used to link (usually just the same as CC)
00:09:00 <junon> yeah I might add a differentiator for CCLD or something. Right now where `E` and `C` refer to the environment and then the build config respectively, I have `C'CC' or E'CC' or DEFAULT_COMPILER` for the executable link steps. I might change it to `C'CCLD' or E'CCLD' or C'CC' or E'CC' or DEFAULT_COMPILER`.
00:09:00 <junon> But haven't run into a case where I need that yet.
00:10:00 <junon> https://git.sr.ht/~qix/oro-build/tree/master/item/oro-build/lib/link/_.lua#L20
00:10:00 <bslsk05> git.sr.ht: ~qix/oro-build: oro-build/lib/link/_.lua - sourcehut git
00:10:00 <junon> But now need to add `ld` support to get the kernel's link script working after migrating from CMake to my own build system.
00:19:00 <junon> are there other common ld names other than `ld` and `lld`?
00:20:00 <junon> and ofc msvc's link.exe but that's not relevant, just curious about linux
00:30:00 <moon-child> lld, bfd, gold, tcc ...
00:31:00 <junon> never seen bfd, what's that?
00:31:00 <moon-child> primary binutils linker
00:31:00 <junon> Forgot about gold, is its CLI based on GNU's or is it its own thing? e.g. lld has ld.lld which runs in GNU compat mode.
00:31:00 <junon> oh I have it installed, neat. I can test it myself, nvm
00:31:00 <moon-child> i mean, probably you're building your own cross toolchain, so you control that environment, no? So you can choose whichever you want
00:32:00 <junon> moon-child: I'm writing a build system
00:32:00 <junon> I want to support each of the linkers ideally.
00:32:00 <junon> I run `--version` on them to determine which CLI variant I should use when translating build options to CLI options when doing rule generation.
00:32:00 <moon-child> oh
00:32:00 <moon-child> use cc to link
00:33:00 <junon> for libraries and executables, yes.
00:33:00 <junon> for scripts it doesn't work as well IME
00:33:00 <junon> e.g. for linking a kernel with an LD script.
00:35:00 <moon-child> if somebody is using a custom linker script, I think it makes sense to make them specify their own linker command-line
00:35:00 <kingoffrance> https://en.wikipedia.org/wiki/Binary_File_Descriptor_library When David Henkel-Wallace of Cygnus Support proposed developing the library as a way to open up new business opportunities for the company, Richard Stallman said that it would be difficult; David's response was that it wasn't such a "Big Fucking Deal"
00:35:00 <bslsk05> en.wikipedia.org: Binary File Descriptor library - Wikipedia
00:36:00 <kingoffrance> thats BFD -- "Big ******* deal" :D
00:37:00 <junon> huh neat
00:38:00 <junon> moon-child: hmm yeah. I don't suppose linker scripts are generally compatible between linkers.
00:38:00 <moon-child> reasonably compatible. But an obscure use case
00:39:00 <junon> I'd rather not tie directly to a specific linker though, that's more my issue.
00:39:00 <junon> But I see your point.
01:52:00 <gorgonical> Developing this hypervisor for arm64 is giving me a painful crash course in just how to configure every part of a linux kernel
02:07:00 <c2a1> gorgonical: link?
02:12:00 <gorgonical> c2a1: It's not wholly my work, but I'm working on the hafnium hypervisor. https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/README.md
02:12:00 <bslsk05> review.trustedfirmware.org: Hafnium - Hafnium
02:13:00 <gorgonical> Hacking it heavily, etc
02:49:00 <geist> noice
02:49:00 <geist> never looked into halfnium that much, though i remember talking to the team members a bit when it was owned by google
04:04:00 <geist> but trying to put together a good type 1 hypervisor for arm64 is one of those things i wanna do some day
04:05:00 <geist> looks like fun if nothing else. sadly riscv seems to have taken the x86 style kinda in their hypervisor extension
04:05:00 <gorgonical> It's looking increasingly like I'm gonna have to (get to?) write my own
04:05:00 <geist> ie, instead of having an run level above supervisor they have a modal switch thing
04:05:00 <gorgonical> We're targeting hpc and so hafnium is sort of not "quite right"
04:05:00 <geist> possible LK might be a starting point?
04:05:00 <gorgonical> I'm not familiar with that one
04:05:00 <geist> littlekernel, my project
04:06:00 <geist> in that you can start from a fairly minimum preemptive SMP kernel, run it in EL2 and build a type 1 out of it
04:06:00 <gorgonical> ah I see
04:07:00 <moon-child> I can never remember--type 1 hypervisor is the cooperative kind?
04:07:00 <gorgonical> I always think of it as "Bare metal" vs "hosted"
04:08:00 <geist> yah, type 1s are kinda out of vogue, and the lines are blurred, but yeah it'd be a specific kernel that explicitly hosts others
04:08:00 <geist> ESXi is pretty close, as well as probably piles of closed source thigns that have anything to do with IBM hardware
04:09:00 <geist> being that arm64 has a proper higher level priviledge level, it seems to be naturally suited for a type 1
04:10:00 <gorgonical> I don't remember who it was, but they were right; arm64 is way nicer as a virtualization architecture
04:10:00 <gorgonical> No more "oh shit vmcs_read itself failed and fucked up the error codes, who knows what went wrong???"
04:10:00 <geist> may have been me, i've been extolling the virtues of it for a while
04:11:00 <geist> what makes it muddy is there's an extension in v8.1 or .2 that if you enable it causes it to look a bit more like x86
04:11:00 <geist> *sort of*
04:11:00 <gorgonical> That's the VHE stuff right?
04:11:00 <geist> yep
04:11:00 <gorgonical> It is not pretty, indeed
04:11:00 <geist> but you see exactly what is for right? it's so you can run a kernel compiled to run at EL1 at EL2
04:12:00 <gorgonical> right
04:12:00 <geist> so that a hosted kernel turns into a type 1
04:12:00 <geist> either it's totally genius or terrible. haven't decided yet
04:12:00 <gorgonical> wait
04:12:00 <gorgonical> I understand the words but not what you mean
04:13:00 <gorgonical> the purpose being that you can e.g. take linux compiled for el1 and use it (kvm or whatever) to host other stuff?
04:14:00 <geist> more efficiently, yes
04:14:00 <geist> w/out VHE you can still take linux and host things, but what happens is the DOM0 (for lack of a better term) still runs at EL1
04:15:00 <geist> and it has to leave a little trampoline at EL2 that it uses to bounce between its guests. standard practice. is how KVM, etc work
04:15:00 <geist> w/VHE you can just run the DOM0 linux at EL2, but without recompiling it because it still thinks it's accessing EL1 control registers
04:15:00 <gorgonical> The idea being that you get to approximately halve the context switches?
04:15:00 <geist> yah
04:16:00 <gorgonical> And I guess there's also less hcr_el2 reconfiguring then
04:16:00 <geist> you avoid a lot of the bounces through EL2
04:16:00 <gorgonical> Because the dom0 needs a special set of values
04:16:00 <geist> yah. probably so
04:16:00 <gorgonical> yeah I see your point. It might be genius
04:16:00 <geist> you could *also* link your host kernel (linux, etc) to just run at EL2 without VHE
04:17:00 <gorgonical> I know I'm late to this party but has anyone seen the quartz64? It intrigues me because it says it has an "embedded risc-v processor" but I don't know what that means
04:17:00 <geist> though i think there may be some other features that are enabled with VHE. I forget precisely if you can easily host a EL0 under EL2 directly (ie have user space) without VHE
04:17:00 * geist looks it up
04:18:00 <geist> https://wiki.pine64.org/wiki/Quartz64 ah looks like it's using some newer rockchip with cortex-a55s
04:18:00 <bslsk05> wiki.pine64.org: Quartz64 - PINE64
04:18:00 <geist> possibly some aux control processor is riscv. fairly common nowadays
04:18:00 <geist> side note: cortex-a55 is i believe v8.2 so it probably has VHE
04:19:00 <geist> though approximately as fast as a cortex-a53 (dual issue, in order, etc)
04:19:00 <gorgonical> I swear I just read this like two days ago. Did I hallucinate reading that??
04:19:00 <geist> well, if it did have some sort of extra riscv i wouldn't be surprised
04:20:00 <gorgonical> well apparently I imagined that
04:21:00 <gorgonical> pine is planning to build a risc-v board, which would be dope
04:22:00 <gorgonical> You know I was checking it out on cpubenchmark and it looks like the rk3566 is actually just as fast as my laptop
04:22:00 <gorgonical> Poor beast is really showing its age
04:27:00 <geist> heh
04:27:00 <geist> if it weren't that web sites are getting more and more complicated, and i tend to leave more and more tabs open i'd generally just say anything in the last 10 years is good enough for me
04:28:00 <geist> but alas, the march of more and more crap going electron and web based...
04:28:00 <gorgonical> indeed. Every day I have at least one instance where I rage that my phone completely locks up trying to visit a mundane website. My phone is not a flagship, but it's still a modern smartphone
04:29:00 <geist> yah it's kinda like being forced to install newer and newer and slower versions of your favorite apps constantly, since the app itself is the pile of js and whatnot that's pulled down dynamically
04:30:00 <geist> and obviously you can just eschew using web pages, etc etc but i'm not willing to go that far
04:30:00 <gorgonical> indeed. I remember about ten years ago it felt like Linux was actually, substantially getting better. Nowadays I just use slackware because I know new stuff won't appear "just because"
04:31:00 <gorgonical> Obviously drivers and good stuff still make it into distros, but I happily use claws as my mail app and I think this release must be like five years old
05:02:00 <radens> I have an ftdi cable which I use for a minnowboard which I want to try hooking up to a raspberry pi 2. The FTDI cable looks like this: https://www.amazon.com/Converter-Terminated-Galileo-BeagleBone-Minnowboard/dp/B06ZYPLFNB
05:02:00 <radens> It probably has the pinout like this: https://microcontrollerslab.com/wp-content/uploads/2020/12/FTDI-cable-pinout-diagram.jpg
05:02:00 <radens> Is there a way to safely use my ftdi cable with my rpi?
05:02:00 <radens> The rpi2 has a pinout like this: https://pinout.xyz/pinout
05:02:00 <bslsk05> www.amazon.com: Amazon.com: USB to TTL Serial 3.3V UART Converter Cable with FTDI Chip Terminated by 6 Way Header, Works with Galileo Gen2 Boards/BeagleBone Black/Minnowboard Max and More : Electronics
05:02:00 <bslsk05> pinout.xyz: Raspberry Pi GPIO Pinout
05:02:00 <radens> whoops I meant to send that to the raspberry pi channel, sorry
05:02:00 <radens> (but if someone has an answer I'll take it anyway :P)
05:25:00 <Affliction> could probably bodge an "adaptor" together with a couple of wires and a similar connector
05:27:00 <Affliction> You'd want to connect GND to GND (naturally), TX to RX, and RX to TX, RTS/CTS are used for hardware handshaking, which the pi doesn't have. They MIGHT be able to be left open circuit?
05:27:00 <Affliction> Or they could be tied to 3v3 or GND as appropriate
05:27:00 <klange> radens: the answer is you get four new dupont terminator terminated cables and plug them into the right bits
05:29:00 <klange> ignore cts and rts; vcc, ground, tx, rx are in that order at pins 4,6,8,10
05:30:00 <Affliction> should VCC be connected?
05:30:00 <Affliction> sure, if that powers the other side of an isolation barrier in the adaptor, but, is that the case with that cable?
05:33:00 <klange> Hm, my rs232 adapter needs the voltage reference, but RS232 is ... weird voltage.
05:33:00 <Affliction> if that's a reference for the data lines, it should probably go to 3.3, not 5
05:34:00 <Affliction> At least, I've killed the original pi with 5V, maybe the newer ones can tolerate it
05:39:00 <Affliction> Something to confirm, if it's sourcing power, you really don't want it connected to anything. If it's a reference, 3.3
05:40:00 <klange> why couldn't they just do rs232 and save us all this mess
05:40:00 <Affliction> cost, I guess
05:41:00 <Affliction> The original design was supposed to be a $25/$35 computer
05:41:00 <Affliction> level shifters and connectors cost money
05:51:00 <klys_> yeah there are so many reasons to usb connector, as I have found at work
07:35:00 <radens> @klange thanks, I'll look into it
07:36:00 <radens> I kind of thought that was the answer (or, buy a new cable), but I was secretly hoping that I could just jam the thing into the gpio header and it would work
07:55:00 <Affliction> Yeah, that'd probably end poorly
08:07:00 <jafarlihi> Hello. I'm kinda new to x86 assembly and can't use Intel manuals as a quick reference. I found project called x86-manpages in GH but wanted to ask if you guys/gals know of any better way?
08:07:00 <jafarlihi> Googling is kinda moot when it comes to asm
08:08:00 <zid> what's your problem with the manual?
08:10:00 <jafarlihi> For instructions I need the 2nd manual, right? Well, for example I want to be able to search "div" and get relevant info right away -- it is rather hard with the manual
08:11:00 <zid> I guess, but scrolling the left bar is fine by me
08:11:00 <zid> I tend to use https://www.felixcloutier.com/x86/syscall if I am being super lazy
08:11:00 <bslsk05> www.felixcloutier.com: SYSCALL — Fast System Call
08:11:00 <jafarlihi> I just want to keep my hands on keyboard
08:11:00 <jafarlihi> I'll check that, thanks
08:11:00 <zid> It's just the manual copy pasted to individual pages
08:12:00 <zid> (I can't imagine needing to look up enough instructions to give a flying fuck how hard it is to look one up, btw)
08:12:00 <moon-child> jafarlihi: x86-manpages probably is fine. But yeah, what zid said
08:18:00 <geist> hmm, finally going back and wiring up io apics and whatnot
08:18:00 <geist> what i haven't figured out without MSIs, how does one assign PCI devices to 'high' global sys interrupts?
08:19:00 <geist> so for example, i have a qmeu here with like 4 ahci controllers, all mapped to 10
08:19:00 <geist> but surely there's a way to assign them individually to higher GSI vectors, but the MADT table doesn't give me any such info
08:19:00 <geist> obviously MSIs mostly supercede this of course
08:21:00 <geist> some references on the interweb to the $PIR table
08:22:00 <geist> ah and then mptable and then via a bunch of methods on devices on the ACPI tables. boo
08:43:00 <geist> oh ugh, reading about _PRT and whatnot. this sucks. can't really sanely support this without a full acpi bytecode interpreter
08:44:00 <zid> Sounds like it doesn't actually have that feature then
08:45:00 <kazinsal> yeah if you can support MSIs it's saner to use those instead of trying to IOAPIC it seems
08:48:00 <geist> yah what's slightly unclear is what happens if you try to use MSIs without properly configuring ioapics and whatnot
08:48:00 <geist> can you simply leave everything in virtual wire PIC mode and then just tell devices to use MSIs and please dont fire IRQs on regular interrupts? (probably)
08:48:00 <kazinsal> well, PCIe doesn't have INT# lines and it uses the MSI mechanism to emulate them
08:49:00 <kazinsal> which the IOAPIC passes through in virtual PIC mode
08:49:00 <geist> sure but generally you disable virtual pic mode (and there's even a ACPI method your'e suposed to call)
08:49:00 <kazinsal> yeah
08:49:00 <geist> but if you just configure a device to use MSI i guess as long as it doesn't try to fire a legacy IRQ all is good
08:50:00 <kazinsal> MSI configuration is mostly done on the LAPICs I think
08:50:00 <geist> also alternatively you can use the mptable, which predates ACPI but probably is still there
08:50:00 <geist> and it also describes how busses wire things to ioapics
08:51:00 <kazinsal> just reading the MSI whitepaper from intel to check
08:51:00 <geist> haven't found a utility on linux to dump the mptable, but freebsd has a utility for it
08:51:00 <kazinsal> yeah, looks like no IOAPIC needed for MSI
08:51:00 <kazinsal> "The MSI model eliminates the devices’ need to use the IO-APIC, allowing every device to write directly to the CPU’s Local-APIC."
08:51:00 <kazinsal> so you can service non-MSI devices through the virtual PIC and MSI devices through MSI
08:51:00 <geist> and i guess it's device specific mechanism to configure it to use MSI and explicitly not fire IRQ
08:51:00 <kazinsal> yeah
08:52:00 <geist> probably this is what i'll do. you either get PIC or MSI but none of the ioapic stuff
08:52:00 <geist> or at least can use ioapic, but just leave it in virtual wire mode
08:53:00 <gog> woo found why my semicolon key was jammed up
08:53:00 <gog> tiny flake of stone stuck under it
08:54:00 <gog> now i can resume code
08:54:00 <j`ey> gog: were you just chaining expressions with , ? :P
08:55:00 <gog> j`ey: no i was just pressing the key really hard instead of fixing the problem :p
08:55:00 <j`ey> hah
08:56:00 <zid> It would have been a fleck of tree, but iceland, so it had to be stone
08:56:00 <kazinsal> MSI enable is bit 16 of the first dword of the MSI capability register in the PCI config space for a device
08:56:00 <geist> word
08:56:00 <gog> tbf tho i'm always hesitant to remove chiclet-style keys because i've broken the little plastic riser thingies too often
08:56:00 <kazinsal> MSI-X requires a lot more per device config
08:56:00 <zid> oh yea, nasty
08:57:00 <zid> similarly, I need to fix my monitor, but I don't dare dismantle it because I am afraid of shitty plastic clips and glue
08:57:00 <geist> kazinsal: yah. also never got it completely straight if it's okay to imeplement a device that is MSI-X only, or does it always have to fall back to MSI, or some combination thereof
08:57:00 <kazinsal> yeah, same
08:58:00 <geist> iirc qemu has some devices that do MSI-X or gtfo, and i thought i remember someone saying that's not technically legal, etc
10:17:00 <klange> since i have this faulty ethernet jack, i added notifications (and correct checking of the UP status bit) to the network status widget so I can see when I've gotten it reconnected
10:18:00 <klange> https://klange.dev/s/Screenshot%20from%202021-11-12%2019-16-47.png demo from qemu
10:18:00 <klange> and when it comes back up: https://klange.dev/s/Screenshot%20from%202021-11-12%2019-18-18.png
10:19:00 <klange> Question for the channel: The orientation of the jack is "correct" - should I make it wrong because it looks more normal upside down?
10:20:00 <Mutabah> I usually think of it as clip at the top
10:20:00 <klange> Much like the ground pin on a NEMA socket, it's "supposed" to be down.
10:20:00 <klange> Er
10:20:00 <klange> Much like how the ground pin on a NEMA socket is supposed to be up...
10:20:00 <klange> the clip is supposed to be down
10:21:00 <klange> "The opposite of what everyone actually does in practice"
10:21:00 <klange> To be fair, like, on laptops you want the clip on the top so you can get your finger into it...
10:23:00 <klange> I think it's supposed to be that the pins are on top so that debris doesn't get stuck on them - like if you leave a port empty it'll collect dust...
10:45:00 <zid> I like the icon other than the pins being very long looking
11:46:00 <sikkiladho> In armv8-a, there are modes and exception levels. User mode is where user applications run, but same is true for Exception Levels. What's the difference?
11:46:00 <sikkiladho> There can different modes in the same exception level?
11:47:00 <sikkiladho> SVC, ABT, IRQ, FIQ, UND,SYS have the same exception level. What is the point of it?
11:48:00 <sikkiladho> reference: https://developer.arm.com/documentation/den0024/a/Fundamentals-of-ARMv8/Changing-Exception-levels
11:48:00 <bslsk05> developer.arm.com: Documentation – Arm Developer
11:48:00 <sikkiladho> I'm reading the programmer's manual but I still have these questions.
11:49:00 <j`ey> i think you should just use EL_x naming with armv8, not modes
12:47:00 <AndroUser2> Why is the raspberry pi is still in beta for arm64
12:48:00 <j`ey> ?
12:48:00 <AndroUser2> Raspberry pi os
12:48:00 <Affliction> I think it's because they want to maintain just one set of binaries compatible across the whole ecosystem?
12:48:00 <Affliction> And maybe proprietary blobs
12:49:00 <j`ey> just use another distro
12:50:00 <Affliction> Yeah, I run debian armv8 on my pi4s
17:44:00 <heat> hello it is me, warmth
17:44:00 <heat> what's up?
17:46:00 <gog> up is the direction opposite to the vector of the gravitational force
17:46:00 <gog> therefore it's relative
17:46:00 <gog> as with all things
17:46:00 <vdamewood> gog: My usual answer is "The direction away from the nearest gravity well."
17:46:00 <heat> hey vsauce, gog here
17:47:00 <gog> lol
17:47:00 <heat> https://www.youtube.com/watch?v=Xc4xYacTu-E
17:47:00 <bslsk05> 'Which Way Is Down?' by Vsauce (00:26:10)
17:47:00 <heat> close
17:47:00 <sham1> Which way is down is such a good video to explain this stuff even though it goes a bit hand-wavy
17:47:00 <gog> the nearest gravity well or the one you're falling into? might not always be the same :D
17:47:00 <GeDaMo> Up is a quark :|
17:48:00 <sham1> Well so is down
17:48:00 <sham1> And beauty
17:48:00 <gog> and top/bottom
17:48:00 * vdamewood reverses GeDaMo chirality.
17:48:00 <GeDaMo> And strange and charm
17:48:00 <gog> GeDaMo: you lepton that pun
17:48:00 <gog> :D
17:49:00 <sham1> Of course everything consists of strings, so be sure to include that .rodata
17:49:00 <vdamewood> gog: I would say the 'most influential', but that would probably be the nearest one since gravity goes doen exponentially in relation to distance.
17:50:00 <gog> true
17:50:00 <GeDaMo> https://www.youtube.com/watch?v=dPRsdQIsqIk
17:50:00 <bslsk05> 'Hawkwind..Quark Strangeness And Charm' by Serdar Koz (00:03:45)
17:51:00 <sham1> Now that is a punny title
17:51:00 <gog> i'm 4 out of 6 quarks bet you can't guess which
17:52:00 <heat> top bottom strange and charm?
17:53:00 <gog> damn am i that predictable
17:57:00 <vdamewood> Why are there no switch quarks?
18:05:00 <gog> vers quark
18:06:00 <heat> quark grindr?
18:06:00 <heat> fissionr?
18:27:00 <chibill[m]> Question is there a good way to test interrupts from C? I tried a divide by 0 but either my compiler is being to smart for its own good or interrupts aren't happening at all.
18:30:00 <sham1> If you're not afraid of using a little bit of inline assembly, on x86 you could do `asm volatile("div $0");`
18:30:00 <heat> the compiler identifies certain things you're doing to trigger exceptions as UB
18:30:00 <heat> which they totally are btw
18:31:00 <heat> things like char *ptr = NULL; *ptr = 'A'; will just give you a ud2 and illegal instruction exception
18:39:00 <chibill[m]> Hm That doesn't trigger my handler nor does it cause a triple fault or anything to happen. :/ Is Qemu doing something weird to me.
18:40:00 <chibill[m]> nvm
18:46:00 <chibill[m]> So its definetly loaded and valid enough not to triple fault but my handler doesn't seem to be getting ran.
18:48:00 <heat> qemu -d int
19:06:00 * geist yawns
19:06:00 <geist> good morning folks
19:06:00 <heat> you mean afternoon?
19:07:00 * heat laughs in GMT+1
19:07:00 <GeDaMo> It's evening! :P
19:11:00 <chibill[m]> I think I need to just start over on setting up the IDT. Think I am doing something wrong in some way.
19:22:00 <geist> it's tricky to get right the first time
19:22:00 <geist> the cpu is not forgiving with things like the IDT and GDT. it just be precisely correct
19:25:00 <chibill[m]> I think my GDT is correct as after implementing it my kernel still works.
19:25:00 <chibill[m]> As much as it does.
19:25:00 <chibill[m]> Now the IDT I have no idea yet.
19:27:00 <j`ey> chibill[m]: if youre using qemu, '-d int' as heat suggested is useful
19:27:00 <chibill[m]> I looked at that but I can't seem to figure out what I am looking at.
19:29:00 <j`ey> it should show you if oure oure getting interrupts
19:29:00 <heat> it's an interrupt log of the vm
19:29:00 <heat> with register state and everything
19:31:00 <geist> we might be able to help if you pastebin one of the reports
19:32:00 <geist> i'm gonna guess its showing an int that immediately gets elevated to double and triple fault because something isn't right on your idt
19:32:00 <geist> in qemu you can also use `info registers` to see if your `lidt` is working properly
19:32:00 <geist> it'll show the base and length field you loaded into it
19:33:00 <heat> I have some questions regarding block devices: Does AHCI define the order in which command lists are executed? And do SSDs have a read head kind of thing or is disk locality not really a thing?
19:34:00 <geist> good question. my guess is no and no, but i can't tell you definitively, since i haven't written an AHCI driver
19:34:00 <gog> afaik disk locality is meaningless for SSDs because of wear leveling
19:35:00 <geist> NVMe though definitely does commands out of order, except where you can insert flushes and barriers
19:35:00 <gog> if it does wear-leveling on the controller anyhow
19:35:00 <gog> and AHCI has NCQ on by default for rotating disks also iirc
19:35:00 <chibill[m]> I would expect a triple fault to cause qemu to reset, it doesn't reset. Here all the output from qemu when running my kernel. https://pastebin.com/re7gC86X
19:35:00 <bslsk05> pastebin.com: SMM: enterEAX=00000001 EBX=00000000 ECX=02000000 EDX=02000628ESI=0000000b ED - Pastebin.com
19:35:00 <geist> yah, i forget precisely how NCQ works, but i think it's fairly implicit to the design that it runs things out of order
19:36:00 <geist> chibill[m]: so which one is the first?
19:36:00 <geist> actually looks like there's only one at the end
19:36:00 <geist> see where the v= line is?
19:37:00 <geist> also see your IDT load, does `IDT= 00103010 000007ff` look correct?
19:37:00 <chibill[m]> yea
19:37:00 <geist> so your first and only interrupt appears to be `0: v=08 e=0000 i=0 cpl=0 IP=0008:0010047c pc=0010047c SP=0010:00107814 env->regs[R_EAX]=00000000`
19:38:00 <geist> that's a double fault, so interesting that it went directly to that
19:39:00 <geist> is there anything special about the PC where it faulted?
19:40:00 <heat> I'm asking because I'm trying to figure out how an IO scheduler should work but it seems to get more complicated when you abandon IDE mechanical drives and go to AHCI/NVMe
19:40:00 <chibill[m]> Weird, I used "char *ptr = NULL; *ptr = 'A';" to cause the interrupt to test.
19:45:00 <chibill[m]> I am guessing something is wrong with my IDT then. Need to write a function to print pointers to see if my IDT is set correctly.
19:50:00 <geist> heat: i think the general trend is dont bother io scheduling. just let the disk deal with it
19:50:00 <geist> hence using nop scheduler on linux with SSDs, etc
19:51:00 <heat> geist, nop also does scheduling, it's not completely nop
19:51:00 <heat> it orders the requests on locality
19:52:00 <geist> chibill[m]: yah also compiler may replace that with something else
19:53:00 <geist> i wouldn't be surprised if the compiler didn't replace your page fault with a ud2
19:53:00 <geist> so if you dont have all the exceptions filled out it might not be firing what you think
19:53:00 <geist> if you want to test the idt i'd highly suggest somethin like `asm volatile("int3");` and verify it in the disassembly
19:54:00 <geist> trying to get the compiler to generate bad sequences is hard
19:54:00 <geist> or at least subtle
19:58:00 <chibill[m]> hm it generates the 03 inttrupt but my handler seems to do nothing.
20:01:00 <heat_> actually isn't sequential SSD performance better too?
20:06:00 <chibill[m]> I am going to re-do all my IDT code to make sure it all makes sense.
20:06:00 <gog> it might be actually
20:06:00 <gog> now that i think about it
20:06:00 <gog> like if the controller knows the mappings for LBA to actual location then it can queue it all up and cache it before doing the writes
20:07:00 <gog> idk enough about it tho i'm pure speculation
20:18:00 <heat> I would think it does some sort of readahead too
20:18:00 <gog> yeah most likely
20:18:00 <gog> since writes are destructive
20:18:00 <heat> since realistically most files are super contiguous and it has a bunch of dram
20:29:00 <chibill[m]> Figured it out. Turns out it helps it you set the address for a table of handlers right. (I was basing my code off both the IDT docs, the Interrupts Tutorial and also XV6)
20:36:00 <chibill[m]> Hm now I get different behavior depending if I run qemu with -d int or not. Without it it works fine, but with it I start spamming GP faults and Double Faults
22:15:00 <heat> chibill[m], fyi IMO xv6 isn't a great source
22:16:00 <heat> you should use something else in all honesty
22:16:00 <heat> it's like they banned comments from source code
22:16:00 <heat> and useful commit messages
22:18:00 <sham1> Not having useful commit messages? Sounds like most companies
22:18:00 <heat> there are commits named "x" and "die"
22:20:00 <heat> they also scrapped the original xv6 because they wanted to migrate to riscv and screw portability am I right
22:25:00 <chibill[m]> Its one that I was familiar with working on, as i had to implement new features into for a CS class a year or two ago.
22:26:00 <chibill[m]> It has a pdf book that explains alot of how it works. :p
22:27:00 <chibill[m]> Yea. They aren't maintaining the original. But hey its their teaching OS :p
22:35:00 <heat> the fact that xv6's code reminds me of FreeBSD isn't great considering xv6 is for teaching and freebsd is a real OS
22:38:00 <Maka_Albarn> Hey, does it matter when you set up the GDT reletive to paging?
22:38:00 <heat> no
22:39:00 <heat> but the GDT needs to be a valid pointer
22:39:00 <Maka_Albarn> thank you. I plan on calling my page table setup from my boot.s, and I wanted to make sure that I didn't need the GDT for that first.
22:39:00 <Maka_Albarn> I'm planning on identity paging the first few MBs
22:39:00 <heat> yeah
22:40:00 <heat> generally you need to do the first bits of paging before the gdt
22:40:00 <heat> since you'll need to switch to long mode when x86_64
22:40:00 * Maka_Albarn nods
22:40:00 <Maka_Albarn> that makes sense
22:40:00 <Maka_Albarn> gotta go, classes.
23:48:00 <geist> though you need at least a temporary one to get into protected mode, etc
23:52:00 <zid> https://cdn.discordapp.com/attachments/518247259838611476/908719631626281030/unknown.png I need to host this somewhere properly so I can give it a memorable uri
23:52:00 <zid> I keep having to find it in the manual to link to people
23:52:00 <kazinsal> the x86 kabbalah
23:54:00 <klange> Any sufficiently funny state transition diagram is indistinguisable from that diagram of equivalences of the holy trinity.
23:54:00 <gog> paging the father, paging the son, and paging the holy ghost
23:54:00 <gog> they're all the same address space
23:54:00 <gog> but different
23:55:00 <kazinsal> plus everyone's favourite, the transitions to "it fuckin' crashes"
23:56:00 <geist> fun new x86 exploit we're fixing right now at work
23:56:00 <geist> 'set hw watchpoint on address; mov (that address), ss; syscall'
23:56:00 <zid> I was about to say
23:56:00 <geist> predict the crazy hijinks
23:56:00 <zid> I don't need new ones I'm still vulnerable to pop ss
23:57:00 <geist> also apparently substitute syscall for int3
23:57:00 <klange> no please stop
23:57:00 <zid> Why are you fixing a 10+ year old exploit?
23:57:00 <klange> I don't even want to imagine what terrible things I've opened myself up to by providing a debug interface...
23:58:00 <geist> i thought this one was newer, like 2018
23:58:00 <geist> pop ss is older, i think
23:58:00 <geist> but it all has to do with the one instruction gap where exceptions are disabled after fiddling with ss
23:58:00 <zid> oh I think maybe it was reported in 2018
23:59:00 <zid> but my cpu from then is vulnerable and won't be fixed
23:59:00 <geist> trick here is it fires a #DB because you hit a watchpoint, but then delays delivering it until the cycle *after* it enters kernel space via the syscall
23:59:00 <geist> so you get a #DB that appears to fire on the first instruction of the syscall handler