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=osdev&y=19&m=5&d=25
12:15:39 <pterp> How do i only debug the VFS in this scenario: Kernel starts init, then init starts VFS. Kernel shares no adresses with init or the VFS, and init and the VFS have overlapping addreses. the kernel, init, and the vfs are all yielding to each other while they do work, and i need to keep debugging after the vfs's first call to yield().
12:16:01 <pterp> Kernel in that post means a task that only runs kernel code.
12:19:52 <doug16k> pterp, you can load symbols for multiple executables at the same time
12:19:58 <doug16k> not overlapping makes that easy
12:20:09 <pterp> i know, but they will overlap and confuse gcc.
12:20:16 <doug16k> gcc?
12:20:23 <pterp> *gdb
12:20:34 <doug16k> oh HAS overlapping
12:21:39 <doug16k> load and unload symbols accordingly
12:22:06 <doug16k> do you use gs for cpu struct?
12:22:15 <pterp> cpu struct? gs?
12:22:24 <doug16k> do you have SMP?
12:22:42 <pterp> WAY too early for that.
12:24:12 <pterp> I also can't tell when a process that i'm not debugging yields, and even if i could, it would happen too fast to switch symbols.
12:24:26 <doug16k> there is no too fast
12:24:43 <doug16k> conditional breakpoint with commands on it, target stops
12:25:10 <pterp> conditional breakpoint?
12:25:39 <doug16k> you can create a breakpoint with a condition on it. condition is checked each time it is hit. you can make it ignored under some conditions
12:25:52 <doug16k> then, you can also attach commands to a breakpoint. it will run them when the breakpoint hits
12:26:15 <doug16k> so you could have one that has a condition that is true when program A is going to get control. there unload and load the right one
12:26:15 <pterp> any better way?
12:26:21 <doug16k> have a 2nd one that does same for 2nd program
12:26:33 <doug16k> bigger way is to implement a multi-process gdb stub
12:26:44 <pterp> How do i do that?
12:28:05 <doug16k> implement this: https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html
12:28:39 <doug16k> my SMP one is a bit huge: https://github.com/doug65536/dgos/blob/master/kernel/arch/x86_64/gdbstub.cc
12:28:49 <doug16k> I need to add multi-process too
12:30:06 <doug16k> nice thing is you can get away with implementing only a tiny portion of the remote protocol, gdb client will fall back to micromanaging the things you don't accelerate by implementing all the commands
12:30:37 <doug16k> gdb will fall back to poking at memory and manipulating cpu registers itself if forced
12:31:21 <doug16k> pterp, all you need is a couple of gdb macros
12:31:27 <doug16k> for this specific thing anyway
12:31:56 <doug16k> define a macro to load 1st program's stuff and another to load 2nd program's stuff
12:32:47 <doug16k> you can even make a macro that checks some variable (check cur_thread->cur_process->command_line[0] == 'i') and knows which one to load
12:35:25 <dormito> doug16k: is everything in that repo GPLv3'd?
12:35:36 <doug16k> ya
12:37:28 <doug16k> didn't put the huge banner all over it though
12:37:49 <dormito> hmm you set it up to use autotools a couple years ago (or at least I've guessing... based on first glance). I personally favor autotools, because what I've seen of cmake (and some of the other alternatives I've seen) failed to impress me. Would you use autools again?
12:38:21 <doug16k> ya probably
12:40:25 <doug16k> autotools generates blazing fast utterly parallel builds, and automates the dependencies without screwing around at all.
12:41:46 <doug16k> utterly pegs my 16 cpu ryzen 2700x and does an obscene number of compiles per second
12:42:01 <doug16k> and that's g++
12:42:10 <chrisf> doug16k: i assume you're into sane nonrecursive autotools at least
12:42:11 <dormito> nice
12:42:27 <doug16k> I don't #include half a billion lines like normal C++ code does
12:43:19 <dormito> chrisf: do you mean recursive make (which really has nothing to do with autotools), or actually recursive autoconf projects?
12:43:24 * geist runs past, smacking the #include out of doug16k's hands
12:43:46 <chrisf> dormito: every project that uses autotools ends up a mass of recursive make nonsense
12:44:04 <doug16k> I don't recurse at all. one glorious makefile at the top
12:44:05 <chrisf> dormito: just due to being the path of least resistance
12:44:20 <dormito> chrisf: no? I've written a fair few that don't (though not public). and that still has nothing to do with autotools
12:45:04 * doug16k looks for the #include. I could have sworn I had one right here
12:45:39 <dormito> hey, geist leaving thos on the floor is a dangerious tripping hazard
12:45:50 * dormito throws #include in the waistbin
12:51:29 * geist gets out a hose and pushes it towards the drain
01:17:12 <xiphias> ciao, !list
01:17:16 <xiphias> (hi)
10:42:09 <blackandblue> do you guys do osdevelopment in VM
10:42:12 <blackandblue> or bare metal
10:43:12 <Mutabah> Testing in a VM
10:44:38 <zid> Eventually you can get away with real hardware
10:44:47 <zid> but doing it without a VM at the start would take forever
10:46:04 <bcos> VM for quick/regular testing; and real hardware when I need to be sure the VMs aren't giving me a false sense of optimisim
10:46:16 <bcos> *optimism
10:47:06 <bcos> Wait.. That's for testing, not development. Development is in Linux on real hardware
10:48:33 <zid> I'm whole hog, I develop in a VM too
10:50:23 <Sjors> my OS ran in various VM environments but never on bare-metal hardware...
10:51:00 <zid> I've got very very low expectations that mine would boot on real hw so I haven't bothered
10:51:04 <zid> my desktop stays turned on
10:52:09 <bcos> My theory is that if you test regularly on real hardware you can fix issues one at a time, and avoid the whole "1234 issues? OMG, too hard!" thing
10:53:24 <zid> two desktops would be nice, for that
10:56:39 <bcos> Nicest is a little LAN of test machines that are configured to boot from network/PXE ;-)
10:58:15 <zid> bcos I need a multi-socket machine with kvm, thanks
10:59:25 <blackandblue> zid: you must be having good hardware
10:59:29 <blackandblue> if you can do dev in VM
10:59:31 <blackandblue> I suppose.
10:59:59 <blackandblue> zid: so you run Ubuntu VM in windows host?
11:00:16 <zid> absolutely not
11:00:24 <zid> gentoo
11:00:32 <blackandblue> in windows host?
11:00:32 <zid> I actually like having working build environments
11:00:34 <zid> yes
11:00:44 <zid> the gentoo image is bootable though
11:00:48 <zid> on my actual m achine
11:00:49 <blackandblue> works just fine?
11:00:53 <zid> of course?
11:00:58 <blackandblue> why not bare metal
11:00:59 <blackandblue> just curious
11:01:05 <blackandblue> for development.
11:01:07 <zid> like 99% of the machines you ever connect to over the internet are probably inside a VM
11:01:17 <zid> because I play too much rocket league etc? :P
11:01:50 <doug16k> why absolutely not ubuntu?
11:01:58 <zid> >I actually like having working build environments
11:01:58 <blackandblue> and that ^
11:02:05 <blackandblue> yea he said that
11:02:09 <zid> I am he
11:02:13 <blackandblue> whats your specs
11:02:15 <blackandblue> if I may know
11:02:23 <blackandblue> I might go that route as well
11:02:27 <blackandblue> dual booting is pain
11:02:28 <blackandblue> :(
11:02:29 <zid> some ddr3 and a 3820
11:03:19 <blackandblue> dell 3820?
11:03:23 <zid> no, cpu
11:03:27 <blackandblue> nvm
11:03:31 <blackandblue> custom build?
11:03:32 <zid> google 'ark 3820'
11:03:38 <zid> people buy prebuilts?
11:03:47 <blackandblue> zid: btw you dont use laptops?
11:03:54 <zid> no I like compiling things
11:03:59 <zid> and ethernet
11:04:06 <zid> and 144hz monitors
11:04:33 <blackandblue> would you recommend me getting the same CPU if I were to build PC now?
11:04:52 <zid> no the socket is too expensive to get a board for, despite sandy bridge-e being super cheap cpu wise
11:05:03 <zid> some garbage 1151 thing is fine
11:05:14 <zid> or 1150
11:05:25 <blackandblue> ok
11:05:32 <blackandblue> zid: you use VMWare or Virtualbox?
11:05:33 <zid> And technically I lied, it's 1 620
11:05:35 <zid> vmware
11:05:41 <zid> qemu for development
11:06:07 <blackandblue> zid: how qemu?
11:06:10 <blackandblue> vm inside a vm?
11:06:14 <zid> yes
11:06:19 <blackandblue> wow
11:06:31 <blackandblue> works smoothly? I am afraid so
11:06:40 <zid> you know cpus do this in hardware right, and it's basically free, performance wise?
11:06:57 <blackandblue> zid: https://ark.intel.com/content/www/us/en/ark/products/64621/intel-xeon-processor-e5-1620-10m-cache-3-60-ghz-0-0-gt-s-intel-qpi.html
11:07:04 <blackandblue> is this the one I should get
11:07:04 <zid> yep that's the one
11:07:14 <zid> 3820 is that cpu with xeon feature bits disabled
11:07:22 <blackandblue> ok time to look for compatible motherboard
11:07:23 <zid> it's a custom part for HP, comes out of a workstation and ebay'd
11:07:29 <zid> good luck not spending $300
11:07:39 <zid> cpu is $30 though :P
11:07:48 <blackandblue> whaat
11:07:55 <blackandblue> CPU is 30 only?
11:07:57 <blackandblue> nice!
11:07:59 <zid> https://www.ebay.co.uk/itm/ASUS-RAMPAGE-IV-GENE-Intel-X79-LGA2011-DDR3-Motherboard/272946380958?epid=115841362&hash=item3f8cdf409e:g:JKEAAOSwbVNbTyzV
11:08:02 <doug16k> I wanna race you on 2700x
11:08:02 <zid> yea but that's the mobo I use lol
11:08:27 <blackandblue> doug16k: yea I am thinking about radeon too. many people are recommending it
11:08:33 <zid> radeon is dead
11:08:36 <zid> 10 years ago
11:08:49 <zid> doug16k: What's cores and clocks on a 2700x?
11:09:03 <zid> I want an 8086k :(
11:09:03 <blackandblue> ryzen sorry
11:09:06 <doug16k> 2700x cpu. 3.9GHz base 8 core, 4.3GHz turbo, 16 SMT
11:09:17 <zid> ah okay so same as mine clocks, but twice the cores
11:09:37 <zid> passmark shows iat as 2200 single thread rating, just barely worse or parity with me
11:09:53 <zid> I can push 2400 if I am willing to cool the chip enough for it
11:09:58 <doug16k> ah but it'll be 16 thread pegged make
11:10:17 <zid> fewer cores is generally better, make has to resolve singular dependancies etc sometimes
11:10:21 <doug16k> not fair there
11:10:48 <zid> My 'base' passmark score is 9k total, 1900 single. 2700x is 17k/2.2k
11:10:52 <doug16k> my ram is DDR4-2400 ECC though, that'll give you a break
11:10:53 <zid> My overclocked is 12k/2400
11:11:07 <zid> It'd cost £40 to replace my ram with ecc
11:11:09 <zid> do it and I'll race :P
11:11:28 <zid> https://www.ebay.co.uk/itm/SK-Hynix-16GB-2x8GB-1600MHz-ECC-REGISTERED-DDR3-PC3-12800R-SERVER-RAM/123775517050?hash=item1cd198817a:g:15cAAOSwr6Rc5AHd
11:11:29 <doug16k> my ram was almost $1k
11:11:35 <doug16k> 64GB of it
11:11:38 <zid> oh it ended
11:11:43 <zid> 32GB for £40
11:11:45 <blackandblue> doug16k: nice!
11:11:55 <blackandblue> doug16k: do you also use windows as host and linux in VM?
11:12:06 <doug16k> no, ubuntu on bare hardware
11:12:25 <blackandblue> default ubuntu? I mean gnome ?
11:12:32 <doug16k> nearly 100% default ya
11:12:35 <doug16k> I don't screw with it
11:12:51 <blackandblue> nice
11:12:53 <zid> boo there isn't as good of a deal left on ebay now
11:13:00 <blackandblue> doug16k: so you dont play games :P
11:13:17 <doug16k> tf2 and ksp a bit
11:13:21 <zid> some guy was selling *three* 16GB kits.. ddr3 ecc is all ran in quad channel lol
11:13:25 <zid> wonder where his 4th kit went
11:13:36 <doug16k> I'm annoying 300+ tour MVM regular
11:13:48 <zid> I played ksp a bit yesterday
11:13:52 <zid> I crashed an asteroid into kerbin
11:14:26 <blackandblue> doug16k: tf2 and ksp works fine on ubuntu?
11:14:34 <zid> almost everything without drm runs flawlessly
11:14:42 <zid> either via steam's linux port push, or wine
11:14:43 <blackandblue> doug16k: nice! whats your specs please?
11:14:45 <doug16k> blackandblue, yes
11:14:53 <blackandblue> I am gonna go full linux now
11:15:04 <blackandblue> zid: no offense but I dont like VMs
11:15:11 <blackandblue> its so slow for my specs
11:15:17 <zid> they're free with hw support
11:15:30 <zid> Like, actually free, if you can measure the performance below 98% I'll give you a sticker
11:16:19 <blackandblue> dota sucked
11:16:21 <blackandblue> on linux
11:16:21 <zid> and my setup is what, nearly 9 years old now
11:16:23 <blackandblue> vs windows
11:16:25 <blackandblue> on same PC
11:16:29 <zid> dota sucks in general Kappa
11:16:30 <blackandblue> 40+ fps difference
11:16:35 <blackandblue> lol
11:16:37 <doug16k> it is Ryzen 2700X 8C/16T 2.9Base/4.25Turbo with 64GB DDR4-2400 ECC, 1TB 960 Pro NVMe M.2 SSD, GTX 1060 3GB, intel I350-T4 quad gigabit nic
11:16:45 <doug16k> I get over 300 fps in tf2
11:17:02 <zid> My gpu sucks, 670 :(
11:17:18 <zid> My machine is 2011 themed though okay? :p
11:17:20 <blackandblue> doug16k: 1060 for linux.. some people might say what a waste
11:17:31 <doug16k> why?
11:17:32 <zid> I'll take a 980ti if anyone has one spare
11:17:37 <zid> because he doesn't understand things
11:17:59 <doug16k> blackandblue, what wouldn't be a waste
11:18:02 <blackandblue> doug16k: because windows supports PUBG
11:18:03 <blackandblue> :P
11:18:03 <zid> "The non DX11 path is not as well optimized in this one game" -> graphics cards on linux are wasted
11:18:07 <zid> appears to be his thought process
11:18:18 <zid> blackandblue: How old are you btw, I'd guess 15?
11:18:28 <blackandblue> 25
11:18:32 <blackandblue> zid: and you?
11:18:41 <zid> 29, getting old :(
11:18:44 <zid> suicide pact soon
11:18:49 <blackandblue> lol
11:18:51 <blackandblue> married?
11:19:09 <zid> I don't think they let people like me get married
11:19:14 <zid> I'm locked in the tower at the top of a castle
11:19:15 <blackandblue> hahah
11:19:19 <zid> I moan loudly when I want feeding
11:19:39 <blackandblue> story of geeks
11:20:12 <doug16k> I want to get a far more powerful AMD GPU
11:21:20 <doug16k> or, maybe instead of that, a dirt cheap intel system with integrated gfx and AMD APU
11:21:20 <zid> trade your ram for it :P
11:21:37 <blackandblue> doug16k: do you use laptop as well?
11:21:39 <zid> I'd be more than happy with a 960 tbh
11:22:11 <zid> Finding one which isn't a bios-flashed fake is kind of hard though!
11:23:45 <doug16k> I am away from home right now on laptop. it is 4th gen core i7 4C/8T 16GB DDR3, 1TB hybrid drive, 17" monitor, GTX 860M, consistently > 100mbit WLAN
11:24:02 <zid> Not bad, does it cook your testicles?
11:24:23 <doug16k> it's 4th gen. no heat issues
11:24:32 <zid> Just depends how they decide to cool them
11:24:33 <doug16k> 4th = haswell
11:24:35 <blackandblue> heat issues in which gen?
11:24:38 <blackandblue> 3rd right?
11:24:44 <zid> I've seen crappy mobile chips hit 100C just plenty
11:24:56 <zid> and they put desktop chips in some
11:25:02 <blackandblue> doug16k: this laptop is also natively running ubuntu?
11:25:07 <doug16k> yes
11:25:25 <blackandblue> doug16k: is it MSI?
11:25:36 <doug16k> Acer
11:26:17 <doug16k> aspire v17 nitro black
11:26:25 <blackandblue> zid: yes they do. I have seen desktop GTX1080 on a laptop
11:27:02 <zid> every 'gaming' laptop I've ever seen died after a couple of years due to thermal issues
11:27:13 <blackandblue> doug16k: do you host your linux configs on github?
11:27:22 <doug16k> this is years old, and rock solid, ready to run a life support unit through usb
11:27:22 <blackandblue> zid: true
11:27:44 <blackandblue> doug16k: its also a gaming laptop so..
11:27:48 <blackandblue> like zid said..
11:28:19 <doug16k> it's not trying to be hyper portable. it's the pizza box sized non-portable fast laptop kind of thing
11:28:51 <doug16k> the heat death ones tend to be trying to be all slick and thin
11:29:27 <zid> doug16k: Even the thick ones, they just don't seem to put them together right
11:29:50 <zid> hmm I might go play zelda
11:30:09 <blackandblue> doug16k: do you host your linux configs on github?
11:30:26 <doug16k> not really. what do you mean config?
11:30:38 <doug16k> dpkg --get-selections?
11:30:48 <blackandblue> .config/
11:30:54 <zid> You can have my linux config if you really want
11:31:01 <blackandblue> zid: yea please
11:32:03 <doug16k> just upgraded 5 minor versions ahead in qtcreator yesterday. amazing improvement
11:32:21 <zid> https://gist.github.com/zid/c679a7f49df76c318d369677b0b6cdc2 There you go ;)
11:32:52 <blackandblue> with the heavy specs you guys have, you dont use cloud right?
11:32:54 <doug16k> you screw around with your kernel?
11:32:58 <blackandblue> thanks zid
11:33:05 <zid> doug16k: Never used a distro kernel
11:33:51 <blackandblue> zid: also, please share your linux config (~/.config)
11:33:59 <doug16k> why?
11:34:05 <zid> I don't have one
11:34:15 <blackandblue> :O
11:34:18 <zid> wait, I do, but the only thing in it is from wireshark
11:34:35 <doug16k> zid, what do you screw around with when you custom build it
11:34:38 <blackandblue> doug16k: its basically i3 and other configs
11:34:41 <blackandblue> vim etc.
11:36:34 <blackandblue> dotfiles basically
11:37:01 <doug16k> I enable write-read-verify on my laptop drive and have write cache off
11:38:49 <doug16k> extended self test (2 hrs) on HDD about once every few months
11:53:06 <zid> doug16k: I just don't build 800MB of modules I won't use, mainly
11:53:18 <zid> kernel build takes about 4 minutes instead of 40 that way
11:57:29 <zid> I mean, you could diff it to see vs yours right? :P
12:06:30 <zid> https://cdn.discordapp.com/attachments/417023075348119556/581815324345761803/unknown.png wasn't kidding btw, playing zelda
12:25:04 <alexander92> hey
12:25:31 <alexander92> guys , i am making a toy kernel , and planning to do it all in "kernel mode
12:25:35 <alexander92> is this a very bad idea
12:26:15 <alexander92> my plan is to just use the physical memory with a type safe mini lang/or runtime checker which ensures apps access only their memory
12:26:45 <alexander92> and to just rotate between running programs in preemptive regime
12:27:39 <zid> yea manged langauges with no context switching is a 'thing'
12:28:48 <alexander92> so
12:29:10 <alexander92> hm, yeah, my plan was to ideally be able to self-host my language
12:29:18 <alexander92> so i can write simple programs using the kernel itself
12:29:45 <alexander92> but i am still not sure what is better: running something like a global language runtime and having programs being "functions" inside
12:29:57 <alexander92> or having more normal "processes"
12:30:06 <zid> They'd just be threads, surely
12:30:22 <doug16k> self host means it can build itself in itself, doesn't it?
12:30:38 <alexander92> well yeah, probably i use a bad def
12:30:57 <alexander92> i meant more that i'll be able to code programs for it inside the kernel itself
12:31:20 <alexander92> like, having a very simple text editor and running my "compiler" inside
12:31:54 <doug16k> cool
12:33:25 <alexander92> but on the other hand i suspect it would be even simpler to just write all my code in the outside language (C or Nim), but i think porting actual existing programs would be harder?
12:33:42 <alexander92> as i plan on totally no compatibility with unix-like stuff
01:30:12 <zid> bcos: https://cdn.discordapp.com/attachments/417023075348119556/581836342011363328/unknown.png Stuff like this is the reason I doubt my thing will boot on my hardware :P
01:32:10 <bcos> Not sure if it'd matter much if it said "Failed to understand ACPI 6" instead of "Failed to understand ACPI 2"..
01:32:31 <zid> https://cdn.discordapp.com/attachments/417023075348119556/581836958662393867/unknown.png Hey, it doesn't always say failed!
01:34:21 <bcos> Probably only take you 10 minutes to make it handle the "RSDP revision 2"..
01:34:26 <zid> I'd love to boot it on my desktop but it'd take me at least 20 minutes to do
01:34:43 <zid> just to see what error it spits out, if it even gets that far
01:34:56 <zid> 20 entire minutes, and I'd have to log back into irc and everything, total ballache
02:13:10 <bluezinc> zid: why would it take 20 minutes?
02:14:41 <zid> figure out something to put it on, shut down all my shit, boot it, restart all my shit, reconnect to all my irc networks and channels, etc
03:17:58 <doug16k> zid, split the difference. make a flash drive with your disk image and put it aside. when you do want to reboot you can try it then
03:24:09 <zid> what if I give it to doug16k, and he reboots instead
03:24:14 <zid> Then we split the work 50/50
03:25:35 <doug16k> I don't want to reboot either lol
03:27:41 <doug16k> I'm streamlining my FPU context save and restore fully. Each thread has a pair of flags, indicating whether to save FPU context when interrupted in user mode or interrupted in kernel mode (and of course whether to restore the FPU context when resuming that thread in user or kernel mode)
03:28:08 <zid> I thought linux had done away with the fpu dirty crap and just always fxsaves or whatever the instruction was because checking the flag is more work
03:28:15 <doug16k> syscalls clobber whole fpu, so I don't want to save anything that way
03:28:39 <doug16k> I'm not doing fpu dirty crap
03:29:01 <doug16k> I'm eliding fpu context save and restore when interrupted in kernel mode
03:29:19 <zid> "Each thread has a pair of flags, ..."
03:29:24 <doug16k> and guaranteeing cleared fpu when syscall returns
03:29:52 <doug16k> a kernel mode thread can enable full FPU capability
03:30:00 <doug16k> default is disabled
03:30:35 <doug16k> a user mode thread could request no fpu
03:31:11 <doug16k> I enforce it with TS bit
03:35:15 <doug16k> let's say they do a syscall to read something, some crap is in the FPU, but it isn't going to be saved or preserved, most likely lost. part way into that syscall, IRQ occurs. I don't save FPU
03:35:39 <doug16k> ...don't save because it was kernel mode interrupted
03:36:18 <doug16k> now that irq wakes some sleeping thread and is rescheduled next
03:36:45 <doug16k> going to load fpu with that other program's context and continue
03:36:55 <doug16k> eventually I go back to that interrupted syscall
03:37:14 <doug16k> now fpu is some other program's fpu - have to clear before returning from syscall
03:37:37 <doug16k> here's the thing: what if I have cleared it and I am about to sysret
03:37:53 <doug16k> ah...
03:38:05 <doug16k> ok I have to make sure that I go uninterruptible before clearing FPU
03:40:56 <doug16k> to be clearer about end bit, plan is to clear fpu on code that is heading into sysret instruction...
03:40:57 <doug16k> but if it were interruptible there it could end up with some other programs fpu after it cleared it
03:51:11 <doug16k> ah, I do need to save MXCSR actually, on syscall entry, and restore it on return with zeroed fpu data registers
03:51:25 <doug16k> and fcw
03:57:44 <doug16k> I'll stick both into the thread object on syscall entry and load them on return
05:42:08 * bcos_ wonders why Intel is still doing the "Execute Disable: Yes" thing on their CPU specs web pages, like it's a feature people don't expect and need to mention it for marketing reasons
06:09:51 <bauen1> would everyone be ok with deleting https://wiki.osdev.org/Page_fault and merging it with https://wiki.osdev.org/Exceptions#Page_Fault ?
06:12:10 <bcos_> bauen1: I can't see why anyone would be worried (or what there is to merge - all the info is duplicated already)
06:12:50 <bauen1> k
06:23:09 <bauen1> is there a reason why the page fault only tells you if you where in CPL=3 (since intel supports more), i mean it's easy to get the value via the cs register, but still ...
06:23:40 <bcos_> ?
06:24:08 <bcos_> CR2 tells you the address that CPU tried to access, regardless of what CPL was (user, kernel, ..)
06:25:42 <bauen1> i'm talking about the protection level, the error code contains a bit to tell you if the fault was in CPL=3
06:25:50 <bcos_> Ah - wait. You mean, why the error code only has a "user/supervisor" flag (and doesn't have a "CPL0/1/2/3" pair of flags)?
06:25:55 * bcos_ nods
06:26:20 <bcos_> That's because paging only has 2 privilege levels - CPL=1 and CPL=2 are treated the same as CPL=0 as far as paging is concerned
06:27:20 <bauen1> oh
06:27:36 <bauen1> alright intels protection levels are just weird
06:40:37 <Sjors> is there actually any proper reason to use CPL=1/2 ?
06:41:38 <Sjors> I've only ever used CPL=0 and CPL=3
06:43:00 <bauen1> normally not, if you're writing a microkernel, they _might_ be usefull
06:43:55 <bcos_> Sjors: If you're using segmentation and you might want "CPL=1 for drivers" maybe. Otherwise I think there was at least one old emulator that used "CPL=1" to emulate "guest CPL=0"
06:54:43 <Griwes> bcos_, I recently learned that there is a flag that disables the flag that enables that feature
06:54:45 <Griwes> amazing design
07:01:23 <Griwes> (I believe it is MSR 1A0H bit 34)
07:02:52 <bcos_> Griwes: Ah - the "execute disable" feature
07:03:28 <Griwes> yes
07:03:46 <Griwes> you have a way to disable the way to enable the feature
07:03:55 <Griwes> it's makes about... 0 sense
07:04:18 <zid> it makes sense if you were using that pagetable bit previously as a flag which wasn't NX, I'd imagine
07:04:22 <zid> before they added NX
07:04:34 <zid> which probably one random embedded device did and regression tracking caught it
07:04:49 <Griwes> zid, you misunderstood
07:05:02 <Griwes> 1a0h:34 doesn't disable the XD bit on page tables
07:05:03 <bcos_> Hrm; not sure if that bit was previously "reserved, fault if set" or "available for OS use"
07:05:24 <zid> then what does it do?
07:05:25 <Griwes> it disables the MSR bit where you enable the XD bit on page tables
07:05:32 <zid> ..what
07:05:37 <Griwes> it makes any attempts to set that bit... fault
07:05:43 <Griwes> I know, right?
07:05:44 <zid> okay then lol
07:06:06 <bcos_> Might be useful if you're writing a malicious boot loader and want to prevent an OS like Windows from using XD
07:06:30 <Griwes> I only learned about this because a person in the local c++ user group had some laptops that kept rebooting when woken up from a sleep state
07:06:36 <Griwes> but only under xen
07:06:40 <Griwes> and only in some cases
07:07:02 <Griwes> turns out on that specific laptop there's a BIOS configuration option to turn that bit on
07:07:05 <zid> Maybe they used it internally for testing is all I can think of
07:07:17 <Griwes> and on some of them it was turned on
07:07:27 <Griwes> and xen didn't check for it and tried to enable XD unconditionally
07:07:41 <Griwes> everything in this industry is ridiculous
07:10:14 <bcos_> Griwes: You think there's something wrong with (e.g.) "BIOS should contain a setup question that allows users to specific when the installed OS does not support CPUID functions greater than 2."?
07:10:16 <bcos_> ;-)
07:10:43 <Griwes> yes
07:11:20 <zid> I don't support cpuid strings without typos
07:11:34 <bcos_> (I personally think that's hilarious - an simple bug in WinNT that could've/should've been patched quickly and easily becomes a hardware work-around forever)
07:12:30 <bcos_> (the old "hardware is hard because it's easy to change, and software is soft because you can't update it" logic)
07:14:08 <zid> all my hardware is made of cheese
07:14:16 <zid> that's kind of soft
07:55:33 <Kazinsal> bcos_: IIRC the bug was in the installer, and sending out millions of patched copies of the installer is a lot more difficult than sending out a patch. Meanwhile, if you're already writing new BIOSes for new boards to support a new processor...
07:56:34 <zid> now it's a marketing feature
07:56:49 <zid> "Unlike our competitors, we support windowsNT" :P
07:57:00 <bcos_> Kazinsal: That's a bit short-sighted though isn't it? I mean, I'm sure Microsoft have fixed the installer by now..
07:57:25 <Kazinsal> It's more about the cost of recalling every Windows NT 4.0 installation disk and sending out new ones
07:57:47 <Kazinsal> Followed by the likelihood that the recall won't be 100% successful; hundreds of thousands of broken installers will be floating around, for sure
07:59:36 <Kazinsal> But if BIOS writers are already working at it, and Microsoft says to Intel "hey can you get them to add a switch to limit reported CPUID leafs to 2" and Intel says "hey guys can you add a switch to limit reported CPUID leafs to 2", you've now solved the problem in an infinitely less invasive and expensive manner than a recall
08:00:07 <bcos_> LOL - apparently they rolled out 7 service packs for NT4 from 1996 to 1999
08:00:11 <Kazinsal> Plus, you've saved face as Microsoft, since you don't have to handle both the logistics and the public reception of a software recall
09:18:54 <pterp> I have a problem. When creating a new task, i need to switch to it's address space to initialize the kernel and usermode stacks. Unfortunately, that means the current kerbel stack isn't mapped, causing a page fault. What's the best way to fix this?
09:22:16 <bcos_> pterp: Allocate physical page for new PML4 and new kernel stack, and map them somewhere in the current virtual address space; then copy all the PML4 entries for kernel space from current PML4 to new PML4; then switch to the new kernel stack in the current virtual address space, then switch to the new PML4
09:22:37 <pterp> i'm in 32-bit x86.
09:22:56 <bcos_> Ah, OK - replace "PML4" with "page directory"
09:24:06 <pterp> the thing is, i have a separate kernel stack for each task, and no task, even in kernel mode, can acess another task's kernel stack.
09:24:35 <pterp> When i say "even in kernel mode", i mean without mapping it in to the current paging structures.
09:25:39 <pterp> and it's likely that the kernel stacks would overlap, so just mapping it into the new address space would not work.
09:26:09 <bcos_> Then you're probably going to have to map it. Doesn't matter if the temporary virtual address is not the same as where it's going to be after
09:26:31 <pterp> see the post right before yours
09:26:48 <pterp> (They most likely would overlap)
09:26:59 <bcos_> Doesn't matter if the temporary virtual address is not the same as where it's going to be after
09:27:13 <bcos_> (e.g. you can map it anywhere you like that doesn't overlap)
10:55:53 <doug_16k> pterp, problems like that are the reason that kernel address space is usually implemented to be the same across all processes
11:56:17 <doug_16k> what would be the fastest way to clear x87 without knowing if the x87 stack were empty? emms ; fldz (repeated 8 times)... ; emms ?