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=18&m=5&d=18
00:00:00 --- log: started osdev/18.05.18
00:00:48 <_mjg_> there is just way too much stuff to annotate by hand and the resulting memory map has seriously combinations of vars in the same line
00:01:34 <geist> yah i was just thinking about that. marking say an int as 64 byte aligned isn't going to make sure that nothing else shares it
00:01:41 <_mjg_> check this out
00:01:42 <_mjg_> ffffffff81413998 B namei_zone
00:01:42 <_mjg_> ffffffff814139a0 B _eventhandler_list_vfs_mounted
00:01:42 <_mjg_> ffffffff814139a8 B _eventhandler_list_vfs_unmounted
00:01:42 <_mjg_> ffffffff814139b0 B mountlist_mtx
00:01:45 <geist> i guess you have to union it with a 64 byte aligned array or something
00:01:53 <_mjg_> fucking namei_zone sharing line with a mutex
00:02:14 <geist> yeah this is what also scares me about the aggressve push by our toolchain folks for using LTO
00:02:19 <_mjg_> where both come from different files
00:02:36 <geist> LTO is like this gigantic shaker when it comes to layout
00:03:09 <geist> make sure someone isn't putting SORT() in the linker script or something. iirc, sorting by size is great for packing stuff in, but causes the linker to rearrange stuff
00:03:39 <geist> i've used it in embedded stuff to sort by size, larger to small, which tends to do pretty good for packing things in
00:03:56 <_mjg_> SORT?
00:04:00 <_mjg_> i need this functionality
00:04:05 <_mjg_> did not know it exists
00:04:18 <_mjg_> it may be it is not supported by the ancient fbsd toolchain
00:04:24 <_mjg_> which is how i failed to find it
00:04:51 <_mjg_> (what i do is __read_frequently and __read_mostly, with the former *typically* being byte-sizes
00:04:54 <geist> binutils ld has had it for a while
00:05:05 <_mjg_> .. but not all of them are and it wastes space)
00:05:17 <_mjg_> with byte and non-byte interleaved
00:05:55 <_mjg_> what does this sort by? just size?
00:06:06 <geist> tryign to find it now
00:06:21 <_mjg_> huh, there are SORT uses in the script already
00:06:26 <_mjg_> i don't know how i missed it
00:07:16 <geist> yah you can sort by sectino name for sure, that's useful if you tag sections with stuff at the end
00:07:29 <geist> SORT(.text.*) kind of stuff
00:07:40 <geist> but... i remember there being some sort of alignment/size sorting thing, i think
00:08:33 <_mjg_> just added it, we will see what happens
00:08:39 <geist> https://sourceware.org/binutils/docs/ld/Input-Section-Wildcards.html#Input-Section-Wildcards talks about it a bit
00:08:41 <bslsk05> sourceware.org: LD: Input Section Wildcards
00:08:42 <geist> SORT_BY_ALIGNMENT, etc
00:09:11 <_mjg_> SORT_BY_ALIGNMENT
00:09:14 <_mjg_> ye
00:10:40 <_mjg_> heh it is descending order, expected the other way around
00:10:46 <_mjg_> but it works, nice
00:10:48 <_mjg_> thanks man
00:11:11 <geist> note that it would tend to change the order that things are in the file relatively 'randomly' which mayu or may not make debugging easier
00:11:15 <geist> or worse
00:11:43 <_mjg_> that's fine
00:11:52 <_mjg_> i have a super hot cacheline
00:12:05 <_mjg_> which will get few more things crammed into it
00:12:23 <_mjg_> you just saved me 5 bytes in there
00:12:31 <geist> yah thats why i was thinkgin almost the only way to do it is the anonyumous union it with a 64 byte array or something
00:12:43 <geist> oh well, that's if you want them to alias, sure
00:12:43 <_mjg_> not sure what you mean
00:12:51 <geist> i was thinking for things that i dont want them to
00:12:59 <geist> like say some spinlock that i want in its own entire cache line
00:13:07 <_mjg_> this particular bit is for things which are pretty much guaranteed to be accessed over and over
00:13:19 <geist> ah yah you can definitely try to cram that in sure
00:13:22 <_mjg_> shit read on syscall entry/exit, and so on
00:16:32 <_mjg_> that said, you may want to look at this https://github.com/antonblanchard/will-it-scale
00:16:32 <bslsk05> antonblanchard/will-it-scale - None (13 forks/15 watchers)
00:17:35 <geist> oh nice, will look at it
00:17:54 <_mjg_> the bit i like about it is the test loop
00:18:04 <_mjg_> it literally is the test itself + counter bump
00:18:22 <_mjg_> and then another thread collects the results
00:18:56 <_mjg_> want some kind of credit for the commit message?
00:21:16 <geist> if you'd like
00:21:46 <_mjg_> well you noted the feature, it's up to you
00:21:48 <_mjg_> 8)
00:21:57 --- join: andrei-n (~andrei@184.206-65-87.adsl-dyn.isp.belgacom.be) joined #osdev
00:22:03 <_mjg_> "Hinted by: "?
00:22:40 <geist> sure!
00:22:50 <_mjg_> what's your full name?
00:22:57 <geist> Travis Geiselbrecht
00:23:32 <klange> Travis Googlebrecht
00:28:33 <geist> https://godbolt.org/g/BQHnSZ putting the int foo in a union that's aligned to 64 seems to be the only way i can get it not to put something in the same cache line
00:28:35 <bslsk05> godbolt.org: Compiler Explorer
00:28:45 <geist> otherwise it sometimes puts baz in the same cache line as foo
00:29:00 <_mjg_> for that kind of stuff you just want a dedicated section
00:29:21 <_mjg_> #define __exclusive_cache_line __aligned(CACHE_LINE_SIZE) \ __section(".data.exclusive_cache_line")
00:29:38 <_mjg_> . = ALIGN(128);
00:29:38 <_mjg_> .data.exclusive_cache_line :
00:29:38 <_mjg_> {
00:29:38 <_mjg_> *(.data.exclusive_cache_line)
00:29:40 <_mjg_> }
00:29:43 <_mjg_> . = ALIGN(128);
00:29:45 <_mjg_> and there you go
00:30:03 --- quit: Pseudonym73 (Remote host closed the connection)
00:30:05 <geist> yeah but you still need to keep it from merging multiple ones. i guess you still want to mark it attribute aligned
00:30:16 <geist> oh duh, i see the __aligned
00:30:17 <_mjg_> the above deals with it
00:30:20 <geist> yeah, that'll do it
00:30:43 <_mjg_> note the potential 64/128 byte woes
00:30:57 <_mjg_> should be more than fine enough for the time being with mere 64
00:31:09 <geist> yepyep
00:31:50 --- join: zesterer (~zesterer@cpc138506-newt42-2-0-cust207.19-3.cable.virginm.net) joined #osdev
00:31:52 <_mjg_> 'Hinted by' did not really work out in the commit message, so you got thanks instead
00:32:21 <_mjg_> https://svnweb.freebsd.org/base?view=revision&revision=333784
00:32:23 <bslsk05> svnweb.freebsd.org: [base] Revision 333784
00:32:38 <_mjg_> shit, it should be 'thanks to'
00:32:41 <_mjg_> well fuck it
00:32:55 <_mjg_> the commit is legit
00:35:59 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
00:37:07 <_mjg_> perhaps i should not be comitting after all nighters
00:47:35 --- join: dafna__ (4d7e3934@gateway/web/freenode/ip.77.126.57.52) joined #osdev
00:48:02 <dafna__> hi, can a page fault happen only when the mmu os turned on ?
00:49:49 --- quit: oaken-source (Ping timeout: 240 seconds)
00:51:59 <Mutabah> iirc yes
00:52:42 <Mutabah> (I assume you mean on x86, can #PF only happen when CR0.PE is set)
00:54:13 <_mjg_> what prompts the question though, are getting sudden resets for no reason?
00:54:18 <_mjg_> are you*
00:55:10 --- join: quc (~quc@host-89-230-167-99.dynamic.mm.pl) joined #osdev
00:56:09 <izabera> why exactly are x86 registers in this order? ax cx dx bx
00:56:47 <klange> you might think their names are just letters
00:56:51 <klange> but they stand for things
00:57:04 <klange> accumulator, counter, data, base
00:57:18 <izabera> yes but
00:57:22 --- join: celadon (~celadon@66.157-14-84.ripe.coltfrance.com) joined #osdev
00:59:10 <Mutabah> "reasons"
00:59:13 <Mutabah> "history"
01:00:08 <geist> _mjg_: nice, you were able to just directly commit? htat's nice
01:01:01 <geist> i wonder if that's the natural encoding order of the registers
01:01:05 <Mutabah> izabera: back in the 8086, each register had something special about it
01:01:07 <Mutabah> geist: it is
01:01:36 <izabera> Mutabah: but why couldn't they just swap the names
01:01:54 <_mjg_> geist: i'm kind of an ass in the project
01:01:56 <_mjg_> geist: :)
01:02:13 <_mjg_> geist: (stupid jokes aside, this kind of stuff does not require review so to speak)
01:02:45 <geist> yah looks like that's the order in the modrm and whatnot
01:02:49 <geist> http://sandpile.org/x86/opc_rm.htm
01:02:50 <bslsk05> sandpile.org: sandpile.org -- x86 architecture -- mod R/M byte
01:03:08 <Mutabah> I'm not 100% sure why it's that order in the beginning? 8008 quirks?
01:03:25 <geist> yeah now i'm actually kind of curious. probably worth looking at the 8080 layout
01:03:56 <jjuran> "account database"
01:03:58 <geist> http://pastraiser.com/cpu/i8080/i8080_opcodes.html
01:03:58 <bslsk05> pastraiser.com: Intel 8080 OPCODES
01:04:30 <geist> but then it's more regular: A, B, C, D, E, H, L, M
01:05:30 <Mutabah> probably just comes from a logical ordering of the purposes?
01:06:06 <Mutabah> Accumulator, Counter, Data, Base - the first two are used pretty often, third is kinda a holding register, fourth is pretty close to being a pointer
01:06:41 <geist> yah and of course you can't just rename them like izabera said, because there are instructions with specific register uses baked in
01:07:27 <izabera> idiot
01:07:54 <geist> well now.
01:08:44 <Mutabah> The ordering was decided all the way back with the 8086, and couldn't be changed due to backwards compatability (and if it ain't broke...)
01:09:04 <geist> it's really the encoding that matters, the names are soemwhat fixed
01:10:17 <geist> wonder if it's the same for the pusha/popa layout
01:10:23 <Mutabah> Think so
01:10:33 <geist> and... yep. it is
01:10:49 <bcos> https://www.nasm.us/xdoc/2.09.04/html/nasmdoc5.html#section-5.1
01:10:51 <bslsk05> www.nasm.us: NASM Manual
01:11:16 <bcos> ^ "Alternate Register Names" macro package
01:11:24 <geist> cute
01:11:46 <geist> guess you could do that with a bunch of .equs or whatnot, but probably works better if it's built in
01:12:33 <bcos> Could invent an entirely different assembly language, with whatever names you like (for registers and instructions)
01:12:47 <klange> steve, bob, phil
01:12:52 * bcos always thought it'd be nice to have a "cpy" instruction, rather than "mov"
01:13:07 <bcos> ..because "mov" actually copies and doesn't move
01:13:21 <_mjg_> :)
01:13:27 --- quit: MarchHare (Ping timeout: 240 seconds)
01:13:48 <_mjg_> do you know the justification for the order of args in memcpy?
01:13:49 <geist> https://retrocomputing.stackexchange.com/questions/5121/why-are-first-four-x86-gprs-named-in-such-unintuitive-order has a decent 8080 -> 8086 answer
01:13:51 <bslsk05> retrocomputing.stackexchange.com: assembly - Why are first four x86 GPRs named in such unintuitive order? - Retrocomputing Stack Exchange
01:14:12 <_mjg_> apparently that's because in c the target of the op is on the left
01:14:21 <_mjg_> that's a quote from mcilroy
01:14:54 <geist> bcos: highly macroed assemblers were a big thing back in the day when you had to write assembly between a bunch of similar machines
01:15:27 <geist> really i think modern assembly usage is generally not nearly as complicated as it was back then when you were expected to write lots of code in it
01:15:47 <geist> CP/M is a good example, it was written in a cpu-neutral assembly language
01:16:53 <geist> PLM I think is what it as called
01:17:30 <mischief> plan9 assembler is sort of machine neutral
01:18:19 <_mjg_> hm
01:18:29 <_mjg_> it sounds kind of iffy, how is this getting optimized?
01:18:42 <_mjg_> by the compiler
01:18:55 --- join: kimundi (~Kimundi@i577A9B84.versanet.de) joined #osdev
01:19:16 <geist> generally was better to have it work at all than work well
01:19:29 <geist> optimizing compilers at the time would have been an amazing luxury
01:19:50 <geist> hell, tons of code was written in interpreted basic at the time, assembly was already a lot faster, even if it wasn't very good assembly
01:20:49 <_mjg_> sounds legit for the old times, was mostly curious about plan9 here
01:20:58 <_mjg_> which is new enough so to speak
01:21:29 <geist> ah, i see. yeah
01:21:34 --- quit: JonRob (Quit: Lost terminal)
01:21:40 <dafna__> _mjg_: hi, it's more a theorethical questions, didnt write any code yet
01:22:28 <izabera> i don't understand why/how interpreted basic was a thing back then
01:23:15 <izabera> in the same age that gave us c
01:23:24 <dafna__> page fault is interrupt number 14, is there any need to implement and interupt handler for it when the mmu is off ?
01:23:25 <Mutabah> simplicity :)
01:23:37 <izabera> simplicity my ass
01:23:40 <klange> compilers were expensive pieces of software you didn't just go and put on micros
01:23:50 <bcos> dafna__: No - page fault can't happen if there's no paging
01:23:50 <geist> C was still largely a 'big machine' thing, as in you ran it on minicomputers and whatnot
01:23:52 <Mutabah> dafna__: It's good practice to have a handler for all 32, with unexpected ones panicking
01:23:54 <klange> basic was cheap as shit to license and run from ROM
01:24:09 <dafna__> ok, and paging is only on when the mmu is on ?
01:24:15 <geist> C compilers would have still been too big to run on machines with 4K/16K ram
01:24:20 <izabera> don't you waste like 90% of what little you have just to run the interpreter?
01:24:34 <geist> ah but you can put the interpreter in ROM
01:24:34 <klange> basic interpreters were tiny
01:24:35 <Mutabah> old basic was a pretty simple language
01:24:54 <Mutabah> And yeah, ROM was relatively cheap
01:25:02 <bcos> dafna__: 80x86 doesn't have a separate MMU that can be enabled/disabled - it just has segmentation and paging "baked in"
01:25:16 <geist> yah 4K rom could support a pretty decent BASIC for something like an 8080 (altair 4K basic is the smallest version)
01:25:27 <geist> though 8K basic is much more full featured with floating point and whatnot
01:25:36 <klange> the commodore 64 basic ROM was 8K, and itw as a more featureful one
01:26:16 <dafna__> bcos: what do you mean "baked in"?
01:26:22 <geist> but for minicomputers or TOPs-10 or whatnot machines in the 70s where BASIC was really born i think the advantage of having an interpreted thing that ran mostly identically between completely differnet cpu/OS architectures was a big win too
01:26:40 <bcos> dafna__: Like, as an integral piece of the design
01:26:43 <geist> since having something work at all is infinitely more useful than having it work well
01:27:19 <izabera> so you're saying that there was a cheap implementation of an interpreter, that could run in very little space
01:27:35 <dafna__> hamm, ok, but what does it practicaly mean ?
01:27:37 <izabera> and there was no cheap compiler, and compilers took too many resources
01:27:37 <geist> i think in general if you had access to a minicomputer or a mainframe and could run code on it you weren't that picky about how fast it ran (within reason)
01:28:12 <geist> right, plus C came along pretty late in the game. if you were doing compiled stuff you were probably doing FORTRAN or whatnot
01:28:13 <_mjg_> anything serious wsa written in assembly, that includes the ataris/commodores/whatever
01:28:13 --- join: light2yellow (~l2y@185.220.70.166) joined #osdev
01:28:21 <geist> right
01:28:26 <_mjg_> basic was basically a toy lang for end users
01:28:32 <_mjg_> i know, i was sone
01:28:35 <bcos> dafna__: It means paging is on when paging is on, and segmentation is always on and can't be disabled; and "when MMU is off" doesn't make sense
01:28:35 <Mutabah> dafna__: It means that the MMU is always there, but it might not be doing anything
01:28:42 <geist> plus C was i think still fairly tied to unix for a long time
01:28:55 <Mutabah> dafna__: (what bcos said)
01:28:57 <dafna__> bsoc: in the linux kernel compilation menu there is an option to disable the mmu
01:29:30 <geist> i have an early C compiler on my Altair when running CP/M called BDS that was surprisingly full featured
01:29:33 <bcos> dafna__: Linux kernel is portable and works on systems where there's the "CPU" as one chip and then an external "MMU" as a different chip
01:29:43 <geist> but it needs a fairly large machine. you need 32K or so to use it
01:29:54 <geist> and it's not really an optimizing compiler
01:30:06 <geist> but it does take C and compile it for CP/M and was mostly written by one dude
01:30:39 <geist> i think fairly late in the game. 1980ish
01:31:17 <izabera> i thought they wrote games in basic
01:31:20 <izabera> for the commodores
01:31:42 <geist> some. and some in assembly
01:31:48 <geist> same for apple 2 and whatnot
01:32:02 <bcos> izabera: They did, but only "very low tech" games - for things like 3D shaders you mostly had to use assembly for acceptable performance.. ;-)
01:32:23 <geist> some in pascal too. i learned the other day that the early Wizardry games were apparently written in UCSD pascal p-code
01:33:08 <dafna__> so paging is in a way happen by default on x86 ?
01:34:37 <bcos> dafna__: "plain 32-bit paging" got added in 80386 (with a bunch of other stuff); then they added PSE paging and PAE paging later (Pentium), then added long mode paging even later (when 64-bit got added)
01:35:07 <bcos> ..so now there's about 4 different flavours of paging to choose from (and "none")
01:35:20 --- join: oaken-source (~oaken-sou@141.89.226.146) joined #osdev
01:35:28 <bcos> ..and Intel are supposed to be adding a "56-bit paging" option soonish
01:35:45 <bcos> Hrm. 57-bit?
01:36:35 <bcos> Anyway - 5 levels (PT, PD, PDPT, PML4 and a new PML5), which is only about 3 too many.. :-)
01:36:43 <geist> 57. not sure it's shown up in silicon yet, though the CR4 bit for it is allocated. i saw it in a manual the other day
01:37:29 <geist> sadly it's all or nothing. you can't enble it conditionally per address space or anything like that
01:37:33 <geist> which would be fairly useful
01:37:49 <geist> you basically need to decide before turning on paging, IIRC
01:39:18 <bcos> I don't really see the point to be honest - there aren't many processes that need it, and the performance hit (for "worst case TLB miss cost") won't be too nice
01:39:43 <geist> clealry someone did
01:40:10 <geist> that's why it's a bummer it's not per address space. seems like it'd be easy enough to set a few bits in the bottom of the cr3 that say 'this is a 5 or 4 level addrss space'
01:40:48 <geist> oh, duh, i know why
01:40:53 <bcos> I wanted 64 KiB page tables and less levels (still with 4 KiB pages)
01:40:56 <geist> because there's only one cr3. keep fogetting that
01:41:23 <geist> arm64 ets you specify the size of the address space per aspace, because they have two cr3-like pointers, one for kernel and one for user
01:41:41 <bcos> "mixed" (some 48-bit, some 57-bit) would be painful for things like PCID
01:41:44 <geist> and based o the size of the aspace different levels 'turn off'
01:41:48 <dafna__> Hi, I read that to enable paging , one needs to set a flag in cr0
01:42:14 <geist> actually i have a task soon to explore using 16KB pages on arm64
01:42:24 <geist> it seems to be a decent compromize, and some hardware actually directly supports it
01:43:09 --- join: Naergon (~Naergon@unaffiliated/naergon) joined #osdev
01:44:03 --- quit: elevated (Quit: bye)
01:44:35 --- quit: Goplat (Remote host closed the connection)
01:44:51 <bcos> geist: I remember Linus saying something about that costing a lot for memory mapped files (especially for file systems using smaller block sizes)
01:45:25 <bcos> Well, mmapped files and VFS in general
01:45:32 <geist> indeed. it's a tradeoff
01:45:57 <geist> anyway sleep time
01:46:11 <bcos> Cya
01:46:14 <zesterer> Filesystems: Can/should they be capable of containing any kind of file? (i.e: block, fifo, etc.)
01:46:30 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
01:50:02 <bcos> zesterer: Any kind, sure
01:50:55 <zesterer> bcos, Right. I'm dealing with files within the filesystem drivers themselves. Does that mean all filesystem drivers need to be able to handle all kinds of file too?
01:51:10 <_mjg_> handle in what sense
01:51:23 <_mjg_> for instance in fbsd the dev nodes on regular filesystems are not supported
01:51:32 <_mjg_> you can create them, but they don't work
01:52:14 <_mjg_> if you are creating a unix-like system, you do need to have a marker for different kinds of files
01:52:15 <izabera> classic user friendly freebsd
01:52:30 <zesterer> Handle in the sense that "managing" the file comes entirely under the domain of the filesystem driver
01:52:50 <_mjg_> for the most part you are supposed to tell vfs what it is and it takes it over from here
01:52:57 <_mjg_> especially so for things like sockets or named pipes
01:53:13 <_mjg_> where the target fs is just a placeholder for the thing at hand
01:53:25 <zesterer> Okay, so VFS becomes the go-to thing for offloading complex bits and pieces that individual drivers don't know how to handle?
01:53:55 <_mjg_> izabera: there is a doc on the subject (or rather: how devfs came to be)
01:54:03 <_mjg_> izabera: i can find it for you if you are interestd
01:54:11 <izabera> sure
01:54:29 <_mjg_> zesterer: well you can implement it however you like, but normally vfs calls into you so that you perform the looup/whatever
01:54:35 <_mjg_> zesterer: and you return the information what you found
01:54:41 <_mjg_> zesterer: and vfs acts on it
01:55:28 <_mjg_> izabera: https://www.usenix.org/legacy/publications/library/proceedings/bsdcon02/full_papers/kamp/kamp_html/index.html
01:55:32 <bslsk05> www.usenix.org: Rethinking /dev and devices in the UNIX kernel
01:55:36 <zesterer> Right... surely that means the VFS holding a long list of "files that aren't actually normal files" and checking against it whenever file I/O occurs?
01:55:46 <_mjg_> no
01:56:09 <_mjg_> you are 'supposed' to have set of arrays of func pointers
01:56:12 <_mjg_> relevant for given file type
01:56:43 <_mjg_> so you have opened a named pipe, you assign a pointer to the array of named pipe ops
01:57:05 <_mjg_> a write comes in and calls whatever the ->write routine is, which in thsi case will be something handling said pipes
01:57:10 <zesterer> Ahhh, so that vtable belongs onto to the file handle, not the inode?
01:57:22 <zesterer> God, that makes so much more sense
01:58:58 --- join: S_Gautam (3bb6f1b0@gateway/web/freenode/ip.59.182.241.176) joined #osdev
01:59:14 --- quit: hmmmm (Remote host closed the connection)
02:00:01 <_mjg_> ye it helps to map out some terminology here
02:00:15 <_mjg_> for instance in linux you got file -> dentry -> inode
02:00:36 <_mjg_> where 'file' is what you translate a fd to
02:00:50 <_mjg_> and inode is the lowest level thing with stuff from the fs
02:02:28 <zesterer> Right
02:04:44 --- join: sixand (~Thunderbi@113.201.117.255) joined #osdev
02:14:21 --- quit: sixand (Ping timeout: 260 seconds)
02:18:54 --- quit: hunterlabs (Ping timeout: 260 seconds)
02:28:17 --- quit: jakogut (Remote host closed the connection)
02:28:42 --- join: jakogut (~jakogut_@162.251.69.147) joined #osdev
02:29:38 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-aghdenlysvqahxol) joined #osdev
02:30:26 --- join: FMan (~fooman@dyttbv349qb9ybg5-w5bt-4.rev.dnainternet.fi) joined #osdev
02:33:01 --- quit: vaibhav (Quit: Leaving)
02:35:03 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
02:45:52 --- join: X-Scale (~ARM@83.223.224.185) joined #osdev
02:53:53 --- quit: light2yellow (Quit: light2yellow)
03:19:00 --- join: hussein (~hussein@45.116.243.77) joined #osdev
03:21:26 --- quit: nur (Ping timeout: 260 seconds)
03:22:55 --- quit: oaken-source (Ping timeout: 264 seconds)
03:23:36 --- quit: S_Gautam (Ping timeout: 260 seconds)
03:30:16 --- quit: newsham (Read error: Connection reset by peer)
03:30:30 --- join: newsham (~chat@udp217044uds.hawaiiantel.net) joined #osdev
03:36:59 --- quit: Humble (Ping timeout: 276 seconds)
03:46:53 --- quit: nortega (Quit: Vivu lante, vivu feliĉe!)
03:49:32 --- join: Humble (~hchiramm@2405:204:d185:211c:c110:7230:2af0:f958) joined #osdev
03:51:09 --- join: lachlan_s (uid265665@gateway/web/irccloud.com/x-ldscrgmudnrupvzh) joined #osdev
03:59:44 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
04:01:58 --- join: CrystalMath (~coderain@reactos/developer/theflash) joined #osdev
04:07:44 --- join: marcthe12[m]2 (marcthe12m@gateway/shell/matrix.org/x-zzgnzxgphtqtlbwy) joined #osdev
04:11:43 --- join: marcthe12 (~marc@138.75.78.56) joined #osdev
04:15:56 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-yxdbbotjeeifjhol) joined #osdev
04:19:31 --- quit: marcthe12 (Quit: Konversation terminated!)
04:20:48 --- nick: marcthe12[m]2 -> marcthe12
04:21:13 --- quit: Humble (Ping timeout: 240 seconds)
04:23:42 --- quit: `Guest00000 (Ping timeout: 276 seconds)
04:34:31 --- join: Humble (~hchiramm@2405:204:d185:211c:838b:f448:9bcd:6c5a) joined #osdev
04:39:07 --- quit: sixand (Ping timeout: 255 seconds)
04:57:53 --- join: ExtremeFMan (~fooman@dyttbv349qb9ybg5-w5bt-4.rev.dnainternet.fi) joined #osdev
05:01:29 --- quit: FMan (Ping timeout: 276 seconds)
05:02:23 --- join: vmlinuz (~vmlinuz@2804:431:f724:7f29:fc35:3076:c137:a268) joined #osdev
05:02:23 --- quit: vmlinuz (Changing host)
05:02:23 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
05:08:21 --- join: Omistaja__ (~fooman@dyttbv349qb9ybg5-w5bt-4.rev.dnainternet.fi) joined #osdev
05:08:32 --- quit: mavhq (Read error: Connection reset by peer)
05:09:49 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
05:11:34 --- quit: ExtremeFMan (Ping timeout: 260 seconds)
05:19:23 --- join: `Guest00000 (~user@37.113.180.34) joined #osdev
05:19:23 --- quit: janemba (Read error: Connection reset by peer)
05:20:00 --- join: janemba (~janemba@unaffiliated/janemba) joined #osdev
05:20:27 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
05:23:08 --- quit: janemba (Read error: Connection reset by peer)
05:24:31 --- quit: immibis (Ping timeout: 256 seconds)
05:40:19 --- quit: pie_ (Ping timeout: 264 seconds)
06:09:48 --- join: Love4Boobies (~L4B@unaffiliated/l4b) joined #osdev
06:13:10 <sahibatko> I cannot find following info in the intel docs, so I will ask here instead: When movq %rax, %cr3 is called, does it take effect immediately or can I call a far jump right after that without having to temporarily map the original code to the old location?
06:13:29 --- quit: elevated (Quit: bye)
06:19:12 <Vercas> sahibatko: It's immediate if paging is enabled, and you're not using PCID.
06:20:59 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
06:22:49 <sahibatko> Vercas: Thanks, bad news for me a little, but still its good to know the cause :)
06:27:02 --- join: S_Gautam (3bb6f1b0@gateway/web/freenode/ip.59.182.241.176) joined #osdev
06:28:31 --- quit: dafna__ (Ping timeout: 260 seconds)
06:29:46 <doug16k> sahibatko, is this in early startup or are you context switching? if you are just context switching, the kernel code should be mapped to the same place in both contexts, then it is safe to mov to cr3
06:30:55 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
06:32:02 --- quit: CheckDavid (Quit: Connection closed for inactivity)
06:38:57 <Vercas> sahibatko: There's another condition that must be met: you're not in (non-virtual) real mode.
06:39:44 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
06:41:54 <Vercas> So, real mode is pretty much the only valid place to hope to change the paging tables without invalidating them...
06:42:07 <Vercas> When you do a real mode to long mode trampoline.
06:43:44 --- quit: vmlinuz (Ping timeout: 260 seconds)
06:43:58 <doug16k> going straight from real mode to long mode is not recommended in intel doc. they tediously spell out the recommended procedure, and it isn't from real to long
06:44:08 <izabera> tfw you end up with something that looks like a valid address in the flag register
06:44:21 <izabera> im having fun
06:44:25 <izabera> kinda
06:44:43 <Vercas> doug16k: I have yet to test on a machine where it doesn't work, though.
06:44:54 <doug16k> izabera, now pushf and ret and have that transfer control to a valid place :)
06:45:00 <Vercas> And I've checked my code against their state machine, it doesn't technically violate it.
06:45:44 <doug16k> Vercas, the doc says plain as day "first get into protected mode, then ..."
06:46:05 <Vercas> Yeah yeah. Imma change it at some point anyhow.
06:46:25 <Vercas> But - for real I never found a machine where it doesn't work, or a hypervisor that breaks it somehow.
06:46:30 <Vercas> And I dunno anybody that did.
06:46:42 <doug16k> when intel documents it like that, I suspect it is their way of saying "on some revision of something you must do this because of errata"
06:47:58 <doug16k> or at least, "we plan to break compat with going straight to long mode someday because it is a pain in microcode"
06:48:07 <Vercas> My code will need minimal modifications to include protected mode anyhow...
06:48:32 <Vercas> As I said, I follow their state machine.
06:48:52 <Vercas> Except I only do one code segment transition.
06:49:14 <Vercas> The only real benefit here is that I get away without a 32-bit GDT.
06:51:19 <doug16k> 32 bit and 64 bit gdt have the same structure
06:53:25 --- quit: sixand (Remote host closed the connection)
06:53:32 <doug16k> Vercas, do you have a link to that code?
06:54:12 <Vercas> doug16k: https://github.com/vercas/Beelzebub/blob/master/beelzebub/arc/amd64/src/ap_bootstrap.asm#L78
06:54:14 <bslsk05> github.com: Beelzebub/ap_bootstrap.asm at master · vercas/Beelzebub · GitHub
06:54:22 <doug16k> thanks
06:55:53 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
06:58:33 --- quit: xenos1984 (Quit: Leaving.)
07:00:17 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
07:04:48 <doug16k> intel says 1) starting from protected mode, disable paging, 2) enable PAE, 3) load CR3 with PML4, 4) set IA32_EFER.LME=1, 5) set CR0.PG=1
07:07:23 --- quit: sixand (Remote host closed the connection)
07:09:18 <doug16k> it doesn't say, enable PAE, set LME, set PG, and slam it into long mode with ljmp
07:09:58 <doug16k> could damage the synchronizer, chip gear teeth, or cause motor mount or driveline damage
07:10:02 --- join: Asu (~sdelang@AMarseille-658-1-108-10.w86-219.abo.wanadoo.fr) joined #osdev
07:10:13 --- nick: hussein -> nur
07:13:40 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
07:16:20 <doug16k> AMD also says, "Before enabling and activating long mode, system software must first enable protected mode"
07:16:20 --- quit: BrainFog (Read error: Connection reset by peer)
07:18:51 --- quit: sixand (Remote host closed the connection)
07:19:30 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
07:21:48 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
07:21:51 <Vercas> doug16k: Pfft, fine.
07:24:34 --- join: pie_ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
07:25:34 <sahibatko> doug16k: still in the "booter", so early stage, but thanks to the mentioned note (map the old code), I am now in the higher half, safe and sound :)
07:26:05 <doug16k> sahibatko, nice
07:27:08 <sahibatko> ... will read the rest of the conversation now ...
07:29:38 --- quit: sixand (Remote host closed the connection)
07:29:59 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
07:33:03 --- quit: sixand (Remote host closed the connection)
07:33:32 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
07:34:03 --- join: hmmmm (~sdfgsf@pool-72-79-162-68.sctnpa.east.verizon.net) joined #osdev
07:34:29 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
07:36:37 --- quit: sixand (Remote host closed the connection)
07:43:55 --- quit: elevated (Quit: bye)
07:47:02 --- join: NaNkeen (~nankeen@115.164.80.206) joined #osdev
07:48:27 --- join: earlz (~earlz@earlz.net) joined #osdev
07:49:08 --- nick: Omistaja__ -> FMan
07:50:53 --- join: millerti (~millerti@cpe-66-24-91-119.stny.res.rr.com) joined #osdev
07:56:53 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
08:00:01 --- join: Asu` (~sdelang@182.202.136.77.rev.sfr.net) joined #osdev
08:00:09 --- quit: Asu (Ping timeout: 276 seconds)
08:01:48 --- quit: NaNkeen (Ping timeout: 256 seconds)
08:05:04 --- join: Asu (~sdelang@AMarseille-658-1-108-10.w86-219.abo.wanadoo.fr) joined #osdev
08:05:04 --- quit: Asu` (Read error: Connection reset by peer)
08:05:31 --- quit: sixand (Ping timeout: 264 seconds)
08:06:46 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
08:10:43 --- quit: sixand (Ping timeout: 240 seconds)
08:10:51 --- join: sixand1 (~Thunderbi@219.145.113.142) joined #osdev
08:13:12 --- nick: sixand1 -> sixand
08:13:19 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
08:30:21 --- join: sixand1 (~Thunderbi@219.145.113.142) joined #osdev
08:30:57 --- quit: sixand (Ping timeout: 256 seconds)
08:30:57 --- nick: sixand1 -> sixand
08:33:38 --- quit: sixand (Remote host closed the connection)
08:35:50 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
08:41:40 --- join: m_t (~m_t@p5DDA3B0E.dip0.t-ipconnect.de) joined #osdev
08:43:54 --- join: KernelBloomer (~SASLExter@gateway/tor-sasl/kernelbloomer) joined #osdev
08:44:56 --- join: janemba (~janemba@unaffiliated/janemba) joined #osdev
08:45:50 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
08:58:55 --- quit: sixand (Ping timeout: 264 seconds)
08:59:53 --- quit: grouse (Quit: Leaving)
09:00:45 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
09:03:24 --- join: quul (~weechat@unaffiliated/icetooth) joined #osdev
09:04:04 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
09:08:14 --- quit: elevated (Quit: bye)
09:09:00 --- quit: sixand (Remote host closed the connection)
09:09:19 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
09:16:20 --- join: bumclock (~user@unaffiliated/bumclock) joined #osdev
09:21:09 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
09:25:07 --- join: ACE_Recliner (~ACE_Recli@c-73-18-225-48.hsd1.mi.comcast.net) joined #osdev
09:27:42 --- join: sixand1 (~Thunderbi@219.145.113.142) joined #osdev
09:28:55 --- quit: sixand (Ping timeout: 264 seconds)
09:28:56 --- nick: sixand1 -> sixand
09:29:50 --- join: daniele_athome (~daniele_a@5.170.120.37) joined #osdev
09:30:44 --- quit: cirno_ (Remote host closed the connection)
09:31:28 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
09:33:39 --- nick: BronzeBeard -> EricB
09:39:37 --- join: gareppa (~gareppa@unaffiliated/gareppa) joined #osdev
09:41:36 --- join: sixand1 (~Thunderbi@219.145.113.142) joined #osdev
09:42:11 --- quit: sixand (Ping timeout: 265 seconds)
09:44:59 --- join: oaken-source (~oaken-sou@p5DDB4F5D.dip0.t-ipconnect.de) joined #osdev
09:45:49 --- quit: sixand1 (Ping timeout: 240 seconds)
09:45:56 --- join: stee3 (~junk@66.252.139.92) joined #osdev
09:46:09 --- quit: daniele_athome (Read error: Connection reset by peer)
09:49:23 --- quit: stee (Ping timeout: 268 seconds)
09:50:41 <lachlan_s> Anyone know how long it generally takes to switch protection modes on modern x86_64 cpus?
09:52:23 --- join: daniele_athome (~daniele_a@5.170.128.204) joined #osdev
09:53:16 <bcos> lachlan_s: Not really - probably about 30 cycles (excluding segment register loads from GDT, if any)
09:53:58 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
09:55:00 <bcos> ..the main cost is likely to be elsewhere - the effect on TLBs and any micro-op/trace caches
09:57:31 --- quit: sixand (Remote host closed the connection)
09:58:38 --- quit: gareppa (Quit: Leaving)
10:00:44 --- quit: cirno_ (Remote host closed the connection)
10:01:22 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
10:01:31 <lava> yes, the cost is very indirect
10:02:10 <lava> i noticed more than 30 cycles though
10:02:18 <lava> was more like 100+ cycles on a skylake
10:02:40 <lava> but still, that's like 25 nanoseconds
10:02:59 <bcos> I think it's probably more like 10 cycles on 80386, so that makes 55 cycles on average!
10:03:05 <lava> :D
10:03:19 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
10:04:49 --- quit: daniele_athome (Ping timeout: 240 seconds)
10:05:15 <bcos> CPU mode switches only really happen during boot (and never happen in "performance critical" nested loops, etc); so there shouldn't be much need for 100% accurate timing information for each CPU
10:05:48 --- quit: drakonis (Read error: Connection reset by peer)
10:10:02 --- join: daniele_athome (~daniele_a@5.170.129.101) joined #osdev
10:11:59 --- join: pounce (~pounce@c-24-11-27-195.hsd1.ut.comcast.net) joined #osdev
10:12:52 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
10:17:38 <pounce> So, for testing purposes I want to create a sort of `assert_interrupt` for my OS. I think I mostly understand how to do this, except for one part. Different interrupts have different iretq behaviour, right? Like #pf returns to the faulting instruction but #bp returns after it. So how do I make a function like this that handles all interrupts and doesn't get caught in a `fault -> iretq -> fault` loop
10:19:21 <doug16k> pounce, the intel manual documents which exceptions are faults, and which ones are traps, and which ones are aborts
10:19:38 <zesterer> pounce, Certain exceptions are supposed to be recoverable.
10:20:07 <doug16k> faults are taken without a change in program state, so iretq will restart that instruction. traps are taken after the change in program state, and return to the following instruction. aborts can't be returned to
10:20:34 <doug16k> the return address pushed to the stack in an abort is not valid
10:20:54 <doug16k> double-fault is an abort, for example
10:23:21 --- quit: cirno_ (Quit: WeeChat 2.1)
10:24:14 <doug16k> pounce, simple answer: you don't even try to do that. each exception needs to be handled specifically. don't do "on error resume next and pretend everything is okay"
10:24:51 --- join: baschdel (~baschdel@2a01:5c0:10:3d11:bca2:7797:3876:4668) joined #osdev
10:25:51 <doug16k> pounce, https://tinyurl.com/y9t84ajg
10:25:58 <bslsk05> tinyurl.com <no title>
10:26:17 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-mkbyzxbuzriwsltr) joined #osdev
10:26:36 --- join: climjark_ (~climjark@c-24-0-220-123.hsd1.nj.comcast.net) joined #osdev
10:28:21 --- join: lldd_ (~atrapado@unaffiliated/atrapado) joined #osdev
10:30:11 --- quit: nur (Quit: Leaving)
10:31:35 <doug16k> pounce, the most straightforward way to handle things like divide overflow is to have a way for a thread or process to register a signal handler. when the divide overflow occurs, the handler adds a return frame at top of stack and jumps to the signal handler. if the signal handler returns it returns to the exception handler and returns to the program. the signal handler can longjmp out and recover somehow
10:33:48 <doug16k> so, if the divide overflow signal handler just returns, then it just keeps restarting the divide forever, as expected. a sensible handler will print a message, clean up somehow, and exit, or longjmp to somewhere and continue
10:39:19 <pounce> makes sense
10:39:22 --- join: hppavilion[1] (~dosgmowdo@74-114-87-80.dynamic.asdk12.org) joined #osdev
10:40:28 --- quit: sixand (Remote host closed the connection)
10:40:30 <pounce> so I have to go back and focus on scheduling XwX
10:42:16 --- quit: Arcaelyx (Quit: Textual IRC Client: www.textualapp.com)
10:43:13 --- quit: Asu (Ping timeout: 240 seconds)
10:43:31 --- join: Asu (~sdelang@174.202.136.77.rev.sfr.net) joined #osdev
10:45:39 --- quit: elevated (Quit: bye)
10:47:05 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
10:50:04 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
10:51:40 --- quit: sortie (Quit: Leaving)
10:53:56 --- quit: S_Gautam (Ping timeout: 260 seconds)
10:54:11 --- quit: sixand (Remote host closed the connection)
10:54:27 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
10:55:16 --- join: hppavilion[0] (~dosgmowdo@74-114-87-80.dynamic.asdk12.org) joined #osdev
10:56:58 --- quit: sixand (Remote host closed the connection)
10:57:02 --- quit: hppavilion[1] (Ping timeout: 256 seconds)
10:58:10 --- join: AverageJ0e (~joe@ip98-167-200-207.ph.ph.cox.net) joined #osdev
11:00:51 --- quit: bumclock (Quit: ERC (IRC client for Emacs 25.3.50.1))
11:05:35 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
11:06:13 --- quit: SlyFawkes (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
11:06:50 --- join: SlyFawkes (5166c138@gateway/web/cgi-irc/kiwiirc.com/ip.81.102.193.56) joined #osdev
11:12:26 <lachlan_s> pounce: Did you look at my scheduler
11:13:04 --- join: nur (~hussein@45.116.243.77) joined #osdev
11:14:20 --- quit: sixand (Remote host closed the connection)
11:15:03 --- join: JonRob (jon@gateway/vpn/privateinternetaccess/jonrob) joined #osdev
11:15:49 --- quit: bauen1 (Ping timeout: 240 seconds)
11:17:45 --- join: bauen1 (~bauen1@ipbcc18c77.dynamic.kabel-deutschland.de) joined #osdev
11:18:08 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
11:18:43 --- quit: Naergon (Ping timeout: 264 seconds)
11:20:39 --- quit: sixand (Remote host closed the connection)
11:24:16 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
11:26:33 --- join: glauxosdever (~alex@ppp-94-66-44-253.home.otenet.gr) joined #osdev
11:30:51 --- quit: sixand (Ping timeout: 260 seconds)
11:33:17 --- quit: vdamewood (Quit: Textual IRC Client: www.textualapp.com)
11:33:53 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
11:35:07 --- quit: nur (Quit: Leaving)
11:36:34 --- join: nur (~hussein@45.116.243.77) joined #osdev
11:44:22 --- join: justanoob (~user@194.135.153.151) joined #osdev
11:44:31 <justanoob> I've got two questions
11:44:53 <justanoob> 1) How x86 rings relate to processor mode? Is there any protection ring difference between real and protected mode?
11:45:17 <justanoob> 2) What exactly determines which ring a process is running on?
11:45:21 <doug16k> real mode is equivalent to ring 0
11:45:34 <doug16k> the DPL of the current code segment determines the current ring
11:45:49 <justanoob> Real mode is always ring 0 then
11:45:55 <doug16k> yes
11:45:57 <justanoob> And in protected mode you can have either 0 or 3?
11:46:02 <doug16k> 0 1 2 or 3
11:46:08 <justanoob> Same for long mode?
11:46:10 <doug16k> but usually only 0 and 3 are used
11:46:13 <doug16k> yes
11:46:17 <justanoob> Alright thank you
11:48:30 --- quit: SM0TVI (Read error: Connection reset by peer)
11:51:27 --- quit: hppavilion[0] (Read error: Connection reset by peer)
11:52:34 --- quit: justanoob (Quit: WeeChat 2.1)
11:55:55 --- quit: daniele_athome (Ping timeout: 264 seconds)
11:57:43 <pounce> lachlan_s: yeah I did. I was planning to do something more like doug16k's "resched on interrupt return" but I may switch to how you're doing things because it seems like most rust OSes (redox, nebulet) do things that way
11:58:22 <pounce> Also I like your homebrew locking primitives, I will have to make some of my own soon too
11:59:44 <lachlan_s> Redox has a pretty poor scheduler
11:59:48 <lachlan_s> It's O(n)
11:59:56 --- join: SM0TVI (~sm0tvi@unaffiliated/sm0tvi) joined #osdev
12:00:10 <pounce> (I mean the context switching itself--that's what I'm dealing with rn)
12:00:35 <pounce> thanks for the heads up
12:05:03 --- quit: tylerdmace (Ping timeout: 268 seconds)
12:06:43 --- join: tylerdmace (~tylerdmac@pool-98-116-102-65.nycmny.fios.verizon.net) joined #osdev
12:07:44 <pounce> since you're using a deque it looks like yours is too though (worst case) ;)
12:09:04 --- join: mra90 (~Martin@host-85-202-159-241.sta.tvknaszapraca.pl) joined #osdev
12:09:26 <lachlan_s> Nah, mines O(1)
12:09:35 <lachlan_s> Deque pops right off the stack
12:09:54 <lachlan_s> Sometimes it copies itself when it has to grow, but that's pretty raw
12:09:58 <lachlan_s> *rare
12:10:43 <pounce> I was just referencing that and being pedantic ;p
12:11:04 <pounce> lachlan_s: (if you don't mind me asking, what year are you? I'm a senior in hs and it says on your github profile that you are in hs too)
12:14:43 --- join: bcos_ (~bcos@58.170.96.71) joined #osdev
12:15:20 <lachlan_s> I'm graduating in a few weeks
12:17:37 --- quit: bcos (Ping timeout: 256 seconds)
12:24:27 --- join: jmill (~textual@72-48-66-51.dyn.grandenetworks.net) joined #osdev
12:32:31 --- join: AvgJoe (~joe@ip98-167-200-207.ph.ph.cox.net) joined #osdev
12:33:12 --- quit: divine (Ping timeout: 255 seconds)
12:34:22 --- quit: AverageJ0e (Ping timeout: 256 seconds)
12:37:33 --- join: S_Gautam (~androirc@unaffiliated/gautams) joined #osdev
12:42:33 --- quit: JusticeEX (Ping timeout: 256 seconds)
12:47:19 <doug16k> lachlan_s, O(1) round robin though?
12:47:55 --- join: divine (~divine@2001:470:8247:2::1000) joined #osdev
12:49:21 --- join: nzoueidi_ (29e211b9@ubuntu/member/na3il) joined #osdev
12:49:25 <doug16k> I need to make my scheduler more SMP friendly, but every time I start tearing it up I revert :)
12:51:03 <geist> well, it's hard
12:51:13 --- quit: AvgJoe (Quit: Leaving)
12:51:18 <geist> perfect is the enemy of good though. start off with essentially no changes
12:51:23 <geist> it wont be optimal, but it'll work pretty well
12:51:28 --- join: Ryanel (~Ryanel@104.220.91.246) joined #osdev
12:53:59 --- join: tacco| (~tacco@i59F4A0E0.versanet.de) joined #osdev
12:57:56 <doug16k> I'm too worried about dynamically balancing the ready queues on the fly. I should just get it working with per-cpu queues with no regard for balance, stabilize that, then worry about balancing
13:00:15 <geist> yes
13:00:56 <geist> zircon currently doesn't balance on the fly, and it works well enough. the main problem is when ou have truly cpu bound threads that never block and thus never get a chance to get their new core figured out
13:01:24 <geist> but that is fairly artificial. generally you dont get that
13:01:53 <geist> but it comes down to a fairly core decision: when does a thread get it's core decided
13:02:01 <doug16k> yeah, by far the common case is threads that wait a lot
13:02:18 <geist> seems that most unices that i've looked at pick the core and stick with it, and then rely on th balancer to fix it later
13:02:30 <geist> whereas zircon/NT and maybe OSX pick every time a thread is unblocked
13:02:58 <geist> so in the second design the thread gets a chance to migrate much more often, and it's only if they never unblock that you end up with trouble
13:03:44 <geist> but then the unix design where you just run the thread on its assigned core independent of whatever the cpu load is and let the balancer figure it out a bit later is somewhat simpler
13:03:48 <geist> though it leans on the balancer
13:03:57 <geist> and may have some real time issues
13:04:26 <doug16k> doing it periodically is nice anyway, it prevents ping ponging threads during transient bursts of activity
13:04:31 <geist> in that design the balancer is much more important
13:04:56 <geist> yes but e careful because that lets you for short periods of time have completely unbalanced queues
13:05:17 <geist> whereas picking the new core to run on every time you unblock tends to maintain balancing automatically, though not perfectly
13:06:46 <geist> it has the instantaneous property of maintaining the invariant that if there's a thread to run, and an idle core, the thread will run *now* instead of n ms later when the balancer runs
13:08:04 --- quit: Asu (Ping timeout: 255 seconds)
13:08:04 --- join: Asu` (~sdelang@AMarseille-658-1-108-10.w86-219.abo.wanadoo.fr) joined #osdev
13:08:14 <doug16k> can't that get into a situation where it keeps moving a thread back and forth?
13:09:56 --- join: MarchHare (~Starwulf@mo-184-5-205-69.dhcp.embarqhsd.net) joined #osdev
13:11:40 <geist> of course, but so can the balancer
13:11:55 <geist> this is why there's no one scheduler. you need to decide what you're trying to optimize for
13:12:13 <geist> low latency responsiveness? throughput? scaling to mega core count? running well on low counts?
13:12:18 <doug16k> I was thinking of low-pass-filtering (like SRTT) the ready queue length of each cpu, and stealing from the cpu with the highest average ready queue length on other cpus
13:13:41 <geist> i think you may be getting slightly ahead of yourself
13:13:44 <doug16k> low pass filter as in avg_len = (avg_len * 0.95) + (cur_len * 0.05)
13:15:49 <doug16k> right now my scheduler is biased extremely toward lowest latency, with no regard for keeping threads on a cpu.
13:18:21 <geist> right, so one strategy is what i'm doidng with zircon where it tries to at least run the thread on the same core it ran on last, which more often than not it can
13:18:37 <geist> it doesn't unnecessarily migrate things around, unless that core is busy, then it tries to find a nearest one
13:19:25 <doug16k> it steals, from the most nearby cpu, when it is going to idle?
13:20:19 <geist> it doesnt. that's the point
13:20:45 <geist> stealing when going to idle is i think a bad idea now. i was just noticing that netbsd does it, but that doesn't scale. *that* tends to make threads needlessly migrate
13:24:30 --- quit: quul (Ping timeout: 255 seconds)
13:26:02 <doug16k> would you agree that the load on a core should be measured as the average number of threads waiting for a turn in the ready queue?
13:28:45 --- join: attah (~attah@h-155-4-135-114.NA.cust.bahnhof.se) joined #osdev
13:29:33 <doug16k> i.e. a core could have 20 threads on it, but if on average only 1 or 2 are ready at any one time, then there is hardly any load. and the other cpu might have 2 threads that wake up and run for 400ms each, and it has more load
13:30:25 <geist> correct
13:30:42 <geist> you may even want to weight it based on number of threads at different priorities
13:30:53 <geist> ie, higher priority threads o the queue may get a higher weight
13:31:06 <geist> somethig like that seems fairly common
13:35:00 --- quit: jmill (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:36:01 --- join: zeus1 (~zeus@197.239.1.32) joined #osdev
13:40:49 <geist> having a periodic balancer is probably the first good start, but make sure you run it only on one core so that you dont end up with all the cores simultaneously trying to balance each other
13:41:03 <geist> from what i remember reading in linux's design, it uses some sort of heirarchial balancer that is topology aware
13:41:18 <geist> and in any given level/group of processors the leftmost one does the balancing
13:41:41 <geist> so it's a seres of balances between the different levels/clusters of cores per level
13:41:53 <doug16k> yeah? how does it balance across them?
13:42:43 <doug16k> if I understood you correctly, the first CPU per node might be responsible for balancing, then who balances across nodes?
13:43:01 <geist> i forget where i read the description, but the gist is i believe that periodically the leftmode core in each separate cluster within each level of topology balances within it's own cluster, then goes up a level and does it for the next level
13:43:11 <doug16k> ah
13:43:20 <geist> and at the end of the day cpu 0 being the leftmost cluster at the top level, it gets the job of moving thhings between nodes
13:43:27 --- quit: Asu` (Ping timeout: 240 seconds)
13:43:34 --- join: Asu (~sdelang@174.202.136.77.rev.sfr.net) joined #osdev
13:43:51 <geist> freebsd iirc just runs a periodic balancer on cpu0 always
13:44:32 <geist> and it does a O(n log n) or whatnot algorithm that tries to find the most loaded and the least loaded node, move threads between them, remove them from the list, then repeat
13:44:51 <geist> so i guess that's technically O(n^2)
13:45:45 <geist> but i think the gist is that idle 'pull' based rebalancing doesn't scale and thus you shouldn't really do it
13:45:58 <geist> that's sort of an 'active' rebalancer
13:46:20 <_mjg_> there is something off about this code though
13:46:32 <geist> which code, the freebsd one?
13:46:35 <_mjg_> i mean even ignoring whether it is effective at the job or not
13:46:38 <_mjg_> fbsd, ye
13:46:50 <_mjg_> it shows up way too much in profiles
13:46:58 <geist> what i can't figure out from looking at it is what happens if cpu 0 is idle? from what i remember it just runs every N ticks of the scheduler
13:47:17 <geist> but then freebsd does have a tickless mode, so it would seem like if cpu 0 was just happen to not running anything, the shceduler wouldn't tick on it
13:47:38 <_mjg_> i'm pretty sure it always ticks at least on cpu 0
13:47:47 <geist> that's my guess, probably for this reason
13:48:13 <geist> it's definitely smarter than say netbsd, which seems to just run a 100hz timer on cpu 0, and all the timeout/callouts are there
13:48:23 <geist> freebsd at least keeps a separate hw timer per core
13:48:26 --- quit: lldd_ (Quit: Leaving)
13:49:34 <geist> that beings aid, i think the freebsd strategy may be what i start with when i get to it on zircon
13:49:45 <geist> it's probably infinitely better than nothing
13:51:09 <geist> i was thinking of just having a timer callback that runs at some rate on cpu 0 that ticks as long as the system isn't completely idle (no threads running on any cores) that just periodically rebalances things
13:51:22 <geist> then it's a pure value add. you can run it or not and it doesn't affect the design much
13:55:28 --- quit: S_Gautam (Quit: S_Gautam)
13:55:38 --- join: Kelpies (~Kelpalots@2600:8803:7880:c5:d0b5:f2f9:e195:b760) joined #osdev
14:01:03 --- join: jmill (~textual@72-48-66-51.dyn.grandenetworks.net) joined #osdev
14:03:45 --- nick: Kelpies -> Android_Wubstep
14:04:43 --- join: n0lan (4dac8cd3@gateway/web/freenode/ip.77.172.140.211) joined #osdev
14:08:38 <n0lan> when kernel return to user from a syscall or interrupt, GS contains the kernel gs that was in msr, when swapgs is executed to return to userspace the old gs (user) was stored in msr and then re-swapped from msr to GS reg?
14:09:22 <geist> right
14:09:35 <geist> swapgs just swaps the values in the two GS_BASE MSRs
14:09:45 <geist> so you need to swapgs on the way in and the way out
14:10:37 <n0lan> two?
14:10:38 <geist> so the GS_KERNEL MSR is really badly named, it's really whatever the alternate one is
14:10:59 <geist> yes, read up on what swapgs does
14:11:16 <n0lan> msr contains one gs value at time, when in kernel it contains the user, when in user it contains the kernel gs?
14:11:17 <geist> it's fairly non obvious until you figure out what it's intended to be fore
14:11:27 <geist> yes, but only as a result of using swapgs
14:11:49 <geist> the cpu does not automatically do any of this, the swapgs instruction is what the kernel uses to make one gs.base active
14:12:21 * _mjg_ mumbles something about unpaired swapgs
14:12:46 <geist> yeah it's a really really bad design. very easy to screw up and have an unpaired swapgs
14:13:01 <geist> though with SMAP it's at least pretty fatal if you mess it up either way
14:13:32 <Android_Wubstep> XD yup.
14:13:52 <geist> this whole gs nonsense is one of my least favorite parts of the AMD 64bit extensions
14:13:58 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
14:15:16 <chrisf> geist: how would you have done it?
14:15:56 <n0lan> why swapgs and not a mov with a known value to avoid the CPL check before to use swapgs everytime
14:16:19 --- quit: zeus1 (Ping timeout: 240 seconds)
14:16:43 <geist> n0lan: mov with a known value where?
14:16:55 <n0lan> from msr?
14:17:03 <n0lan> so have 2 msr and not only one
14:17:07 --- quit: bauen1 (Remote host closed the connection)
14:17:08 --- quit: glauxosdever (Quit: leaving)
14:17:14 <geist> chrisf: i had a pretty good thought once. but off the top of my head if you want the exact same mechanism you could have a control bit in eflags or whatnot that just specifies which one is active
14:17:15 <n0lan> kernel_base and user_base
14:17:25 <geist> that would be more fool proof, and would restore itself on the way out
14:17:44 <geist> n0lan: there are two. you're missing the point of what swapgs does
14:17:48 <_mjg_> n0lan: part of swapgs magic is that you are interrupt and preemption-safe
14:18:03 <n0lan> so: mov gs, kernel_base does always the samething and we are sure that gs contains kernel gs
14:18:15 <geist> myguess is amd didn't want to add any more rflags bits
14:18:43 <geist> secondarily they could have and should have added the fsgsbase instructions right then, instead of having to wait 10 years for intel to add it
14:18:44 <n0lan> from here I see only one https://www.felixcloutier.com/x86/SWAPGS.html
14:18:45 <bslsk05> www.felixcloutier.com: SWAPGS — Swap GS Base Register
14:19:32 <geist> n0lan: dont be confused with the value that is in gs and what gs.base points at
14:19:44 <geist> for the most part the value in gs is completely irrelevant in 64bit mode (with one caveat)
14:19:49 <n0lan> isn't it user gs?
14:20:07 <geist> as with most things in x86 it's complicated
14:20:24 <geist> depends on if user space is 32bit or not. if it's not and user and kernel is both 64bit, then the value in gs is largely irrelevant
14:20:31 <geist> and is typically set to 0
14:21:10 <n0lan> so if we are in 32bit mode that gs base is the user gs?
14:21:11 <geist> the fS_BASE and GS_BASE MSRs are basically backdoors to the hidden 'base' part of what is loaded when you fiddle with gs (in 32bit mode)
14:21:33 <geist> no. the gs is a selector in user space that points to an index in GDT/LDT that has the base field
14:21:39 <geist> in 32bit mode. in 64bit mode it does nothing
14:21:47 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
14:22:26 <n0lan> geist, ok so it is not the kernel gs, so the kernel is stored in GS and the user in msr
14:22:33 <geist> ...
14:22:34 <n0lan> at elast from the doc I see only one msr
14:22:43 <geist> it's complicated. not sure where to start
14:22:51 <geist> and it has everything to do with if you're in 32bit or 64bit mode
14:22:58 <geist> soince the mechanism completely changes
14:23:13 <geist> therre are 3 MSRs dealing with fs and gs, fs has 1, gs has 2
14:23:19 <geist> swapgs deals with the gs ones
14:23:51 <n0lan> one msr is used to keep KERNEL_BASE, right?
14:23:52 <geist> and yes, i see why you're confused, the docs you linked dont mention the other MSR
14:24:02 <n0lan> yeah
14:24:07 <geist> yes, one MSR returns points at gs.base essentially
14:24:16 <geist> that's usually called IA32_GS_BASE i believe
14:24:19 <n0lan> and what other msr does?
14:24:28 <geist> IA32_KERNEL_GS_BASE
14:24:34 <n0lan> yes
14:24:34 <geist> that is what swapgs swaps with
14:24:43 <geist> it just exchanges the values in the two msrs
14:25:04 <geist> and as a result since the IA32_GS_BASE is the same thing as gs.base, it also swaps what gs.base
14:25:16 <n0lan> with the gs base in GDT where register gs reg in userspace contains the index
14:25:18 <geist> so it depends on a matter of perspective what it's swapping with
14:25:35 <geist> ehhhhh, not really
14:25:40 --- quit: m_t (Quit: Leaving)
14:25:49 <geist> it exchanges entirely whats in the gs.base internal register on the cpu. has nothing at all to do with whats in the GDT
14:26:07 <geist> the GDT is only used as a source for loading gs.base (in 32bit mode) when you write to the gs register
14:26:22 <n0lan> wait, lets start form userspace, there is a syscall or interrupt, and gs contains the GDT index for userspace gs.base, right?
14:26:24 <geist> but once it's laoded it can change independent of what happens with GDT
14:26:38 <geist> if you'd like. is user space 32bit?
14:26:46 <n0lan> yes
14:26:50 <geist> and kernel is 64bit?
14:27:01 --- quit: jmill (Ping timeout: 260 seconds)
14:27:10 <n0lan> let assume kernel 32bit too, for now
14:27:20 <geist> swapgs is 64bit only (as far as i know)
14:27:23 <sortie> You need to log in before you can see this message from sortie. Please insert and touch your security key.
14:27:31 <n0lan> oh, ok!!
14:27:44 <CompanionCube> sortie: my security key is you
14:27:49 <n0lan> so ok, kernel 64bit
14:28:00 <sortie> Your own personal sortie, reach out and touch me
14:28:01 <geist> swapgs is 64bit only because otherwise the GDT is irrelevant with segments in 64bit mode, so you need another mechanism to fiddle with gs.base
14:28:11 <geist> you can't just reload the gs selector in kernel space like you used to do in 32bit kernels
14:28:18 <n0lan> ok
14:28:27 <n0lan> user 32bit, kernel 64bit for now
14:28:38 <geist> if it were a 32bit kernel you could just reload gs with the kernel selector in the first few instructions in the syscall or interrupt
14:28:42 <sortie> Honestly it gets old to touch your 2FA key all the time at work. I made it a bit more fun by making a chain of paperclips attached to the security key that I can just yank.
14:28:51 <geist> but since that mechanism no longer works in 64bit, AMD invented this swapgs hack to get you another way to do it
14:29:23 <n0lan> so, in user and kernel 64bit, gs is irrelevant?
14:29:23 <geist> it's basically a backdoor hack to accomplish what you always did on 32bit to work around missing 64bit functionality
14:29:27 <geist> correct
14:29:36 <n0lan> but swapgs is not, right?
14:29:39 --- quit: qweo (Ping timeout: 256 seconds)
14:29:41 <geist> loading a segment register in 64bit doesn't really do anything anymore (with a few caveats)
14:29:57 <chrisf> sortie: this is what better keyboards have usb ports for...
14:30:06 <n0lan> as far as I know, gs contains per-cpu struct in kernel
14:30:24 <n0lan> that contains the kernel stack maybe
14:30:26 <geist> be very specific. you mean specifically gs.base points at it
14:30:35 <n0lan> yes, right
14:30:44 <sortie> chrisf: Hehe
14:31:11 <geist> the RSP0 kernel stack is still loaded form the 'tss'
14:31:18 <n0lan> what gs points when in userspace, mostly?
14:31:20 <geist> well, okay actually not in syscall, i think
14:31:31 <geist> up to user space
14:31:42 <n0lan> oh, ok
14:31:47 <geist> on unixy systems i believe fs is traditionally used for TLS, and gs is used for whatever
14:31:54 <geist> i've heard of some runtimes using it. java, dart, etc
14:32:49 <geist> since user space usually can't directly set fs.base and gs.base (unless the os enables the fsgsbase instructions on newer cpus) there's usually a syscall to let user space set it to whatever theyw ant, and it's saved with the thread state
14:34:14 <geist> the fact that AMD only added a swapgs and not an equivalent to swapfs was basically because at the time the standard was to use gs: in the kernel and not fs:
14:34:27 <geist> presumably they looked at what other systems were doing and decided to implement the minimal needed
14:34:47 <doug16k> so how do you mindread which cpu you are on in 32 bit mode?
14:35:05 <geist> cpuid
14:35:12 <doug16k> ya a bazillion cycles
14:35:22 <geist> so it goes.
14:35:37 <doug16k> at least swapgs allows near zero overhead pointer to cpu local state
14:36:02 <n0lan> so bck to msr, what about the second msr register? in the doc I see that only IA32_KERNEL_GS_BASE is used to keep kernel gs base
14:36:13 <geist> the other one is IA32_GS_BASE
14:36:14 <doug16k> swapgs is not perfect by any means but it is a good speed improvement
14:36:27 --- quit: andrei-n (Ping timeout: 256 seconds)
14:36:30 <geist> which when you read/write it directly modifies gs.base
14:37:19 --- quit: oaken-source (Ping timeout: 264 seconds)
14:37:32 <geist> so yo can consider it a window into the gs.base previously hidden internal register
14:37:48 <geist> same as IA32_FS_BASE
14:38:45 <geist> and now to be more complicated, there are a set of new instructions on i believe haswell and above that lets you directly access fs.base and gs.base. see https://www.felixcloutier.com/x86/RDFSBASE:RDGSBASE.html
14:38:47 <bslsk05> www.felixcloutier.com: File Not Found
14:38:58 --- join: jmill (~textual@72.32.180.183) joined #osdev
14:39:51 --- quit: zesterer (Ping timeout: 260 seconds)
14:40:48 <doug16k> n0lan, IA32_KERNEL_GS_BASE is not named correctly. it should be IA32_SWAPGS_GS_BASE. IA32_KERNEL_GS_BASE holds the other value for GSBASE that is not in effect
14:41:01 <geist> yeah, it's really the alternate
14:41:27 <n0lan> doug16k: not mentioned in intel docs
14:41:43 <doug16k> n0lan, look at the docs for SWAPGS
14:41:50 <doug16k> (in volume 2)
14:42:32 <geist> there's a MSR table in there too
14:42:43 <geist> it's the MSRs right next to KERNEL_GS_BASE
14:42:53 <geist> you need them anyway to save the fs/gs state on context switch
14:43:08 <geist> or load them
14:43:16 <geist> (prior to the fsgsbase instructions existing)
14:43:20 <doug16k> yeah you won't find my proposed name in there... I'm saying what it should be named. the current name (with _KERNEL_) is not appropriate because it does not hold the kernel GS base when you are in kernel mode and have swapped gs
14:43:31 <n0lan> it is the same that I see here https://www.felixcloutier.com/x86/SWAPGS.html
14:43:53 <geist> okay, sure but look for it somewhere else
14:44:03 <geist> technically swapgs doesn't mention it because that's not what swapgs does
14:44:09 <n0lan> it is the same content of volume 2
14:44:20 <n0lan> ok, let me check in msr
14:44:30 <n0lan> it is always in volume 2?
14:44:31 <geist> it doesn't swap the MSRS, it swaps the KERNEL_GS_BASE msr with gs.base, it just so happns there's another MSR that always 'points to' gs.base
14:44:36 <geist> which i've told you like 3 times now
14:44:44 <doug16k> instructions are documented in volume 2. the msrs would be in volume 3
14:44:47 <n0lan> oh ok
14:45:22 <geist> i always think of it as swapping the two msrs, but really it's not, which is what the swapgs does tell you
14:45:58 <doug16k> swapgs does swap the two msrs. the actual gsbase and the "kernel" gsbase
14:46:02 <doug16k> how is it not?
14:46:22 <geist> because the swapgs docs say otherwise, which is what was confusing n0lan
14:46:38 <geist> it says it swaps KERNEL_GS_BASE with fs.base
14:46:41 <geist> which is technically true
14:47:09 <doug16k> tmp ← GS.base; GS.base ← IA32_KERNEL_GS_BASE; IA32_KERNEL_GS_BASE ← tmp;
14:47:16 <geist> yep
14:47:38 <n0lan> what is GS.base in that case? the content of GDT?
14:47:42 <geist> and then somewhere else assign IA32_GS_BASE = GS.base
14:47:43 <doug16k> that's the pseudocode in the swapgs docs
14:47:46 <doug16k> n0lan, the MSR
14:48:06 <geist> i think we're just gonna confuse em with more MSR talk
14:48:07 <n0lan> ok, but I don't see it in the doc :D
14:48:22 <n0lan> so how do you know that it is msr?
14:48:31 <geist> oh dont make me fire up the intel docs
14:48:38 <n0lan> I got your point, but I can't see it int he doc
14:48:40 <doug16k> GS.base and the GSBASE MSR are the same thing
14:49:23 <doug16k> loading gs with a selector which selects a descriptor with 0x12345678 as the base loads the GSBASE MSR
14:49:38 <doug16k> loading 0 into GS zeroes the GSBASE MSR
14:49:49 <geist> so searching for GS_BASE in volume 3 yields 8 hits
14:50:13 <geist> vol 4 is really the gold mine, since it's entire name is 'volume 4: Model-Specific Registers'
14:50:36 <geist> table 2-19
14:50:55 <n0lan> A new 64-bit mode instruction, SWAPGS, can be used to load GS base. SWAPGS exchanges the kernel data structure pointer from the IA32_KERNEL_GS_BASE MSR with the GS base register. The kernel can then use the GS prefix on normal memory references to access the kernel data structures. An attempt to write a non-canonical value (using WRMSR) to the IA32_KERNEL_GS_BASE MSR causes a #GP fault.
14:50:57 <doug16k> you don't see people loading gs to load the gsbase msr because you can't load an offset greater than 32 bits that way, hence, nearly useless to do that. therefore, people use wrmsr to load GS.base
14:51:22 <n0lan> it says gs register, not msr
14:51:40 <geist> n0lan: okay i'm starting to get frusterated here
14:51:43 <doug16k> no it doesn't. it says the gs base register
14:51:53 <geist> we've told you about 15 times. GS.BASE ========== IA32_GS_BASE MSR
14:51:58 <geist> it's the same damn thing
14:52:08 <doug16k> MSR = machine specific _REGISTER_
14:52:10 <n0lan> I trust you guys, but I want just to read this in the doc :D
14:52:19 <geist> n0lan: volume 4, table 2-19
14:52:25 <geist> has the list of all the architectural MSRs
14:52:43 <geist> and it's mentioned about 8 times in volume 3
14:52:47 --- quit: awang (Ping timeout: 268 seconds)
14:53:02 <geist> table 2-2 is better
14:54:02 --- join: zesterer (~zesterer@cpc138506-newt42-2-0-cust207.19-3.cable.virginm.net) joined #osdev
14:55:33 <n0lan> read it, thanks
14:55:43 <n0lan> I rememer why I hate intel manuals
14:55:53 <geist> suggestion: use the single pdf version
14:56:08 <geist> unless your computer is too slow, i just load up the mega version that way you get hits across all the volumes
14:56:18 <doug16k> n0lan, see page 3988, chapter 35.1
14:56:21 <geist> also suggestion: read the AMD manuals. they tend to be more succinct and clearer
14:56:24 <doug16k> (combined manual)
14:56:37 --- quit: attah (Remote host closed the connection)
14:56:41 <geist> double so since these MSRs are an AMD addition
14:57:28 <doug16k> you can't "find" C0000102 because that table has wordwrap, it's C000_<newline>0102 D:
14:57:49 <n0lan> crap
14:57:57 <geist> heh, but IA32_GS_BASE is definitely all over the place
14:58:12 <geist> fun fact too: ia64 machines have MSRs as well, and they occupy the same namspace
14:58:17 <geist> hence why there are IA32_* prefixes
14:59:17 <geist> i dunnno all the rules about accessing IA64_ MSRs from ia32 emulation mode and whatnot
15:00:33 --- join: zeus1 (~zeus@197.239.1.32) joined #osdev
15:01:13 <n0lan> ok, so on 64bit user and kernel, the KERNEL_GS_BASE is still gs.base in gdt?
15:01:43 <doug16k> if you load gs it loads that from the descriptor, but the descriptor only has 32 bit base
15:01:57 --- quit: MarchHare (Ping timeout: 256 seconds)
15:02:08 --- quit: vmlinuz (Quit: Leaving)
15:02:32 <doug16k> if you load 0 into gs, it zeroes the gs base msr
15:02:49 <geist> yah though that's a place where AMD and intel differ
15:02:55 <geist> and iirc it matters based on what was already in gs
15:03:12 <geist> though i'm probaby wrong on the second part
15:03:17 --- quit: CheckDavid (Quit: Connection closed for inactivity)
15:03:50 <doug16k> in long mode, the cpu doesn't care about ds, es, fs, gs anyway, so it's not really an issue. you'd just set the MSR(s) appropriately and forget the data segment registers
15:04:05 --- quit: jmill (Read error: Connection reset by peer)
15:04:27 <doug16k> in compatibility mode, it cares, because 32 bit code cares
15:05:14 <doug16k> it does a full segment_base + offset calculation on every access in compatibility mode (32 bit)
15:05:45 <geist> right, which is why loading ds/es/fs/gs still actually *does* something in 64bit mode, it just generally doesn't care about the result
15:05:54 <geist> and i think only if it' a 32bit segment
15:06:13 --- join: jmill (~textual@72-48-66-51.dyn.grandenetworks.net) joined #osdev
15:06:15 <geist> reason being you still need to be able to actually load the segment registers with meaningful 32bit stuff before switching to a 32bit user space
15:06:27 <n0lan> well, but gs in 64bit still contains the address of per-cpu struct, so it cares?
15:06:38 --- quit: mra90 (Quit: Leaving)
15:06:47 <geist> yes, but you can't get a full 64bit address from the GDT
15:06:58 <doug16k> n0lan, when you use gs or fs in long mode it uses those base MSRs
15:06:59 <geist> because the GDT entries aren't expanded to be 64bit
15:07:20 <doug16k> right, which is why nobody uses that to load fs base or gs base
15:07:34 <geist> doug16k: i think they're still the same. the MSRs are just pointing at the same .base, it just can't be meaningfully manipulated in 64bit mode
15:07:44 <geist> via the segment registers
15:08:26 <geist> i guess for that matter it means the fs.base and gs.base are actually 64bit internally, whereas ds/es wouldn't need to be because you can't actually get a 64bit value into them
15:09:01 <geist> well anyway, this is not what i wanted to fill my brain with again today :)
15:09:03 <doug16k> right
15:09:34 <n0lan> :)
15:09:55 <doug16k> basically, amd wanted to do away with the segment base/limit crap, because it is not really used. then they realized, oh crap, people use that for thread-local-storage, so they provided special case for fs and gs
15:09:57 <n0lan> I think I read all this stuff years ago, but I don't remember it again
15:10:15 <geist> right
15:10:36 <doug16k> then they realized, it would be nice for a kernel to cache a permanent cpu-local-struct pointer, so they thought, let's use gs... but then they realized, oh crap, user mode code can overwrite that, so, they added swapgs and that "other" gs base msr
15:10:37 <geist> so they added a window into an existing mechanism via the simplest hack they could come up with
15:10:45 <geist> yah
15:11:17 <_mjg_> eh
15:11:25 <_mjg_> i'm getting old
15:11:40 <geist> my main complaint s that as a hack it's fairly dangerous. easy to misuse, and easy to point kernel at user space, etc
15:12:19 <geist> hardware that toggles state like that is generally bad
15:13:42 <n0lan> ok, so here comes another question, why they can't use mov gs, kernel_base or user_base to enter and exit to syscall/int handlers instead of check if CPL is 0 or not before swapgs?
15:14:05 <geist> because that's not how it works at all
15:14:35 <geist> remember gs is a *selector*. it's a 16 bit register that in 32bit mode is an index into the GDT, and in 64bit mode is basically vestigial and does nothing
15:14:43 --- quit: kimundi (Ping timeout: 265 seconds)
15:15:05 <geist> you can't just move into it
15:15:27 --- quit: ACE_Recliner (Ping timeout: 240 seconds)
15:15:51 <doug16k> n0lan, let's say the user mode code reads ds and writes gs. then it smashed the gs base. your kernel is unaffected, when you enter the kernel, you swapgs, and bring back the gs the kernel wants, and the user mode's crap gs base is safely moved to the other msr
15:16:39 <doug16k> then, when returning to the user mode code, you swapgs again, stashing your pristine kernel gs base in the other msr and bringing back user mode's crap gs base
15:16:56 <n0lan> ok, makes sense
15:17:46 <geist> also remember the point of this is to have a different kernel gs base per cpu. if you're SMP, each core has it's own gs.base
15:18:16 <geist> and thus even if you used rdgsbase/wrgsbase instructions at the top of your interrupt/syscall code to load the kernel base, you still have to be able to know which cpu you're on to find the right one
15:18:20 <doug16k> ^ right, on one cpu you could just use a global variable and be done with it.
15:18:25 <geist> yah
15:18:39 <doug16k> but on SMP, you can't efficiently determine the current cpu without gsbase
15:18:51 <geist> correct
15:19:06 <geist> if you're single cpu you dont really need to use gs: at all in the kernel, really
15:19:12 --- quit: Shamar (Quit: leaving)
15:19:15 <geist> and you probably shouldn't. the overhead/complexity is probably not worth it
15:19:23 <n0lan> how it affect this? swapgs copy msr into gs, so it is the same of an hipotetically mov gs, msr_kernel_base
15:19:26 <geist> you can just have a global variable that points to your state
15:19:43 <geist> again. i've said it a few times gs, itself is a *selector*
15:19:49 <doug16k> n0lan, no, you put selectors into segment registers, not base addresses
15:19:52 <geist> it does not hold the base, gs register is vestigial in 64bit mode
15:20:02 <n0lan> yes..
15:20:02 <geist> it is a 16 bit register that basically does nothing
15:20:06 <doug16k> and you can't put a base bigger than 32 bits in a descriptor
15:20:14 --- quit: rain1 (Remote host closed the connection)
15:20:23 <geist> you *have* to use the MSR (or wrgsbase) to get a 64bit base into gs.base
15:20:25 <geist> it's the only way
15:20:48 <geist> that's why i keep saying you have o be precise. gs is a select. gs.base is an internal 64bit register
15:21:38 <n0lan> ok
15:22:04 <doug16k> n0lan, when you enter the syscall handler, how do you tell which gsbase to load into gs? mindread the current cpu? use incredibly expensive cpuid instruction? that's the point of having a gs base that can be protected from user mode smashing it
15:22:28 <doug16k> which gsbase selector to load*
15:22:40 <n0lan> doug16k: well, swapgs does the same, it moves the msr of sme cpu that swapgs is running
15:22:43 <doug16k> it's useless to load selectors for that for reasons I already mentioned
15:25:05 <doug16k> it doesn't do the same. for the 3rd time, even if you did try loading gs with a selector to do it, it can't load a base larger than 32 bits. therefore, it is useless. your kernel data structures will almost certainly be at an address way too high for a 32 bit base to be useful
15:25:36 <n0lan> yes, yes
15:25:51 <n0lan> I got it :) I was talking about the possible SMP issue
15:26:20 <doug16k> and if you somehow did have your cpu-local-struct at a low address, it still doesn't solve anything. the whole point of gsbase is the cpu caching the pointer to the cpu-local-struct in an msr and easily reading/writing it with gs segment override prefix
15:26:48 <geist> yah. and it's extremely frequent that you need it almost immediately inside your isr/syscall
15:26:59 <geist> it's basically the root pointer for your local state
15:27:20 --- join: AverageJ0e (~joe@ip98-167-200-207.ph.ph.cox.net) joined #osdev
15:27:27 <geist> for example, you may store a poitner to the current thread in our current cpu struct
15:27:29 <doug16k> n0lan, in my kernel it takes exactly one instruction to get a pointer to the currently running thread
15:27:37 <geist> so that you can do something like gs:0x8 to get your current thread pointer
15:27:42 <doug16k> ^
15:27:42 <geist> exactly
15:27:46 <doug16k> thinking in stereo
15:28:06 <geist> and current cpu # could be say gs:0x10
15:28:13 <geist> which is also needed a fair amount
15:28:44 <doug16k> yes. and I put a pointer to itself at gs:0 so I can do additional accesses to it without gs prefixes
15:28:51 <geist> right
15:28:58 <doug16k> this_cpu() returns gs:0
15:29:04 <geist> fairly standard good ideas
15:29:24 <geist> other architectures (like arm) usually have a spare 'msr like' registe for this
15:29:38 --- quit: Asu (Remote host closed the connection)
15:29:43 <geist> something you can stash away that user space wont trash that you can restore on kernel entry
15:31:47 <doug16k> https://github.com/doug65536/dgos/blob/master/kernel/arch/x86_64/cpu/segrw.h
15:31:49 <bslsk05> github.com: dgos/segrw.h at master · doug65536/dgos · GitHub
15:32:45 <doug16k> first one compiles to one instruction, the offset is a compile-time-known constant
15:33:33 <doug16k> second one can take an offset as a parameter, which is nearly zero cost as well
15:34:50 <geist> yeah
15:35:17 --- join: immibis (~chatzilla@222-155-160-32-fibre.bb.spark.co.nz) joined #osdev
15:35:25 <geist> would be interesting to see if you can collapse those two to avoid haing to get the offset into a reg
15:35:37 <geist> i discovered the other day that you can specify more than one constraint in the ""
15:35:47 <geist> so you can, i think do, something like "Ir"
15:35:57 <geist> i use something like that in zircon for a similar thing
15:36:41 <geist> https://fuchsia.googlesource.com/zircon/+/master/kernel/arch/arm64/include/arch/arm64/mp.h#68
15:36:42 <bslsk05> fuchsia.googlesource.com: kernel/arch/arm64/include/arch/arm64/mp.h - zircon - Git at Google
15:36:47 <doug16k> geist, I gave up on that a long time ago. think it would work?
15:37:08 <geist> basically the [offset] field may end up being a constant (most of the time) or a reg, and the compiler seems to do the right thing
15:37:30 <geist> similarly you can if yo need to wrap the whole thing with an if (__builtin_constant_p(offset)) and spit out two versions
15:37:39 <doug16k> I know clang makes dumbass choices when you do that sometimes. gcc probably does it better
15:37:42 <geist> which is what i was doing until one of our toolchain folks pointed out i can use "Ir"
15:37:53 <geist> clang seems to do it just fine too, i verified the dissassembly
15:38:11 <geist> what was tripping it up was compiling with -O0, where it basically refused to constantify the offset arg
15:39:18 <geist> in this case it's for arm and it just so works out the instruction form can cant a constant or a reg there
15:41:39 <doug16k> https://bugs.llvm.org/show_bug.cgi?id=31525
15:42:03 <doug16k> with rm clang won't ever pick r, it picks m every time
15:43:55 <doug16k> the stack misalignment part is not really a problem, x86-64 will realign. the other part is really bad, it generates a store then ltr's from there
15:44:23 * geist nods
15:45:47 --- quit: rafaeldelucena (Ping timeout: 256 seconds)
15:46:05 <doug16k> 17 months later, unassigned, zero comments. lol
15:46:43 <geist> yeah pure microoptimizations like that are probably fairly low on the totem pole
15:46:47 <doug16k> I'm reporting the next clang bug I encounter to my friend's cat. she has more chance of fixing the issue
15:47:09 <geist> we actually have folks on our team that directly patch it
15:47:16 <geist> but this one doesn't have a clear answer it hink
15:47:48 <doug16k> I am shocked though because this is about as trivial as contraints get
15:48:08 <doug16k> other than just "r"
15:48:14 <geist> what's weird is it's all 16 bit
15:48:21 <geist> what's going on there? I thought trs are not
15:48:30 <doug16k> tr is a segment register
15:48:32 <geist> oh it's a segment selector
15:48:33 <geist> got it
15:50:02 <geist> fascinating that the godbolt link still works
15:50:08 <geist> i'd assume those short links would age out
15:50:33 <doug16k> clang 6.0.0 still does it too :)
15:51:02 <geist> yah
15:51:09 <geist> red zone it still pushes it
15:51:23 <geist> i wonder if it's some short 'high part of register is undefined' sort of thing
15:51:45 <geist> where it doesn't know what your instruction will care if the top of the register has crap in it so it picks the safer option
15:53:12 <geist> doesn't seem to matter, been fiddling with different topions
15:53:21 --- join: rain1 (~rain1@unaffiliated/rain1) joined #osdev
15:54:40 <doug16k> gcc sensibly does `ltr %di`
15:54:59 <geist> yeah i'm fiddling with differne toptions and it's really strange
15:55:56 <geist> seems that in the multi constraint case it just always prefers m over r
15:56:11 <geist> there doesn't seem to be any other way to interpret it
15:56:35 <geist> and if you change the order of them it doesn't matter either
15:57:21 <geist> fun that if you force it to m gcc at least maintains 8 byte stack alignment
15:58:34 <geist> well good for reminding me, i'll double triple check that i didn't break it on clang on zircon
15:58:52 <geist> if i did then maybe i'm in luc and i'll attach my problem to the bug and since we have clang devs on the team...
15:59:10 <doug16k> cool
15:59:35 --- quit: `Guest00000 (Ping timeout: 248 seconds)
15:59:48 <geist> but i'm almost positive i looked at it and it was good, but that was arm64 so
16:02:32 <geist> yeah, it does the right thing
16:03:40 <doug16k> nice. yeah, I'll update the non-template version of mine to have Ir, then at least it has a chance of constant-propagating it to the one-liner
16:05:04 <geist> yah note that I may be specific to arm64. i think it basically means 'a constant that's suitable as an offset to a load/store'
16:05:14 --- quit: xenos1984 (Quit: Leaving.)
16:08:20 <doug16k> right, "I" is in range 0 to 31 for x86 (it's for 32-bit bit shift immediates)
16:09:56 <doug16k> "e" is probably the most correct for x86, "32 bit sign extended immediate"
16:10:36 --- quit: jmill (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:11:16 --- quit: n0lan (Quit: Page closed)
16:11:17 --- join: jmill (~textual@72-48-66-51.dyn.grandenetworks.net) joined #osdev
16:13:41 <doug16k> if offsetof(cpu_info_t, something) ever grows larger than 2GB, it will fallback to "r" and still work. lol
16:16:52 --- quit: jmill (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:20:34 --- join: jmill (~textual@72-48-66-51.dyn.grandenetworks.net) joined #osdev
16:21:57 --- quit: zesterer (Ping timeout: 240 seconds)
16:24:19 --- quit: zeus1 (Ping timeout: 265 seconds)
16:31:29 --- quit: sortie (Quit: Leaving)
16:33:29 --- quit: KernelBloomer (Quit: Leaving)
16:40:55 --- quit: JonRob (Quit: Lost terminal)
16:57:13 --- quit: dude12312414 (Ping timeout: 240 seconds)
17:00:38 --- quit: booyah (Read error: Connection reset by peer)
17:03:06 --- quit: quc (Ping timeout: 256 seconds)
17:08:16 --- join: zeus1 (~zeus@197.239.1.32) joined #osdev
17:12:28 --- quit: jmill (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:14:24 --- join: jmill (~textual@72-48-66-51.dyn.grandenetworks.net) joined #osdev
17:15:22 --- join: booyah (~bb@193.25.1.157) joined #osdev
17:16:00 --- quit: lachlan_s (Quit: Connection closed for inactivity)
17:20:35 <pounce> omg is it "spectre" because "speculative execution"
17:21:17 <Mutabah> Yes.
17:21:17 <Shockk> yes
17:21:19 <Shockk> lol
17:21:20 <pounce> I never realized this
17:21:25 <Shockk> well you did now
17:21:30 <Shockk> that's what counts
17:21:32 <pounce> I just thought it was an edgy name they chose
17:21:39 <Shockk> it is
17:21:39 --- join: promach__ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
17:21:43 --- quit: zeus1 (Ping timeout: 248 seconds)
17:21:50 <Mutabah> it's an edgy pun
17:25:40 <bcos_> Someone should write a spectre vulnerability detection tool, and call it "inspectre"
17:26:29 --- nick: promach__ -> promach2
17:26:34 <clever> spectre-meltdown-checker is a package within nixos
17:26:54 <clever> nix-repl> spectre-meltdown-checker.meta.homepage
17:26:54 <clever> "https://github.com/speed47/spectre-meltdown-checker"
17:26:55 <bslsk05> speed47/spectre-meltdown-checker - Spectre & Meltdown vulnerability/mitigation checker for Linux (299 forks/2259 watchers)
17:27:26 <pounce> hehe
17:33:20 --- quit: jmill (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:35:17 <variable> \o/
17:35:18 <variable> |
17:35:19 <variable> /\
17:41:39 --- quit: baschdel (Ping timeout: 255 seconds)
17:44:54 --- quit: AverageJ0e (Ping timeout: 256 seconds)
17:46:19 --- quit: millerti (Ping timeout: 264 seconds)
17:49:46 --- quit: variable (Quit: /dev/null is full)
17:50:50 --- join: vaibhav (~vnagare@125.16.97.122) joined #osdev
17:52:49 --- quit: jjuran (Read error: Connection reset by peer)
17:53:37 --- join: ACE_Recliner (~ACE_Recli@c-73-18-225-48.hsd1.mi.comcast.net) joined #osdev
18:00:04 --- join: quc (~quc@87.116.237.92) joined #osdev
18:05:31 --- join: zeus1 (~zeus@197.239.1.32) joined #osdev
18:12:23 --- quit: bork (Ping timeout: 248 seconds)
18:13:57 --- join: ljc (~ljc@unaffiliated/ljc) joined #osdev
18:13:59 --- join: bork (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
18:22:13 --- join: dude12312414 (None@gateway/shell/elitebnc/x-zngzhoedgrbbbdkc) joined #osdev
18:25:27 <dmh> does anyone know the current fastest arm64 chip off the top of their head
18:25:31 <dmh> dumb ideas ahoy
18:27:49 <_mjg_> probably it will be thunderx2
18:30:07 --- quit: bork (Ping timeout: 264 seconds)
18:30:50 --- join: bork (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
18:32:11 <doug16k> bcos_, https://www.grc.com/inspectre.htm
18:32:13 <bslsk05> www.grc.com: GRC | InSpectre
18:32:43 <bcos_> Dammit
18:33:54 <geist> dmh: fastest by single core performance?
18:34:04 <geist> or total throughput or whanot?
18:35:53 <doug16k> bcos_, someone should make a tool called inspectre gadget that actually performs a spectre exploit instead of checking for microsoft updates and microcode versions that supposedly mitigate it
18:35:56 --- quit: matviy (Ping timeout: 260 seconds)
18:36:23 <geist> you just want an excuse to make something called inspectre gadget
18:36:40 <bcos_> Yes :-)
18:37:19 --- quit: quc (Ping timeout: 264 seconds)
18:37:59 <bcos_> Hmm - would Apple's latest chip (A11 Bionic?) win for single core?
18:38:20 <geist> that's what i'd probably argue
18:38:34 <geist> most of the cortex-a7* class are pretty high end too
18:39:03 <geist> at least on paper
18:39:25 <geist> trouble is they're typically put in smartphone class chips with limited power draw and memory bandwidth
18:46:03 <bcos_> Hrm - Nvidia's "Denver" looks like it's got some freaky stuff going on.. "Out of order: Not if hardware decoder in use. Can be provided by dynamic translation to VLIW"???
18:49:55 <geist> yep. denver is well known to be a transmeta like design
18:50:02 <geist> one of the reasons i wont go near it
18:50:13 <geist> supposedly a bunch of the ex transmeta folks ended up there
18:55:35 <bcos_> Heh - might just be people emulating ex transmeta folks! :-)
19:01:28 --- join: oaken-source (~oaken-sou@p5DDB5628.dip0.t-ipconnect.de) joined #osdev
19:07:30 --- join: NaNkeen (~nankeen@122.0.31.67) joined #osdev
19:08:34 --- quit: booyah (Read error: Connection reset by peer)
19:12:12 --- quit: ljc (Quit: ayy)
19:15:47 <dmh> geist: yea i was thinking simple , like a solid SoC
19:15:59 <dmh> i have an asus tinker board and its really impressive
19:16:22 <dmh> i want to make another toy OS, but arm64 only. no x86 (my only experience so far)
19:16:45 <dmh> before it gets just as kludged
19:27:09 --- quit: zeus1 (Ping timeout: 256 seconds)
19:28:30 --- join: ljc (~ljc@unaffiliated/ljc) joined #osdev
19:38:55 --- quit: JusticeEX (Ping timeout: 268 seconds)
19:38:55 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
19:41:15 --- join: jjuran (~jjuran@c-73-132-80-121.hsd1.md.comcast.net) joined #osdev
19:46:31 --- join: AverageJ0e (~joe@ip98-167-200-207.ph.ph.cox.net) joined #osdev
19:50:14 --- quit: ALowther (Remote host closed the connection)
19:57:07 --- join: MarchHare (~Starwulf@mo-184-5-205-69.dhcp.embarqhsd.net) joined #osdev
20:04:19 --- quit: tacco| ()
20:04:45 --- quit: MarchHare (Quit: Leaving)
20:05:27 --- quit: nj0rd (Ping timeout: 240 seconds)
20:05:56 --- quit: ACE_Recliner (Ping timeout: 260 seconds)
20:08:47 --- join: unixpickle (~alex@c-24-5-86-101.hsd1.ca.comcast.net) joined #osdev
20:10:41 --- join: zeus1 (~zeus@197.239.1.32) joined #osdev
20:11:27 --- quit: Tobba (Read error: Connection reset by peer)
20:12:36 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
20:18:46 --- join: sixand (~Thunderbi@113.201.119.72) joined #osdev
20:20:38 --- join: nj0rd (~nj0rd@i577BC090.versanet.de) joined #osdev
20:28:06 --- quit: Ryanel (Ping timeout: 256 seconds)
20:29:58 --- nick: Android_Wubstep -> Kelpie
20:30:44 --- quit: cirno_ (Remote host closed the connection)
20:31:24 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
20:31:59 --- quit: CrystalMath (Quit: Support Free Software - https://www.fsf.org/)
20:33:48 --- quit: zeus1 (Ping timeout: 268 seconds)
20:34:49 --- quit: NaNkeen (Ping timeout: 240 seconds)
20:35:24 --- join: absurdistani (~bradford@136.59.70.115) joined #osdev
20:35:52 --- join: lachlan_s (uid265665@gateway/web/irccloud.com/x-okttvfrmjdoydknp) joined #osdev
20:37:32 --- join: NaNkeen (~nankeen@203.188.234.181) joined #osdev
20:37:55 --- quit: sixand (Ping timeout: 264 seconds)
20:47:46 --- join: Ryanel (~Ryanel@104.220.91.246) joined #osdev
21:00:44 --- quit: cirno_ (Remote host closed the connection)
21:01:13 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
21:01:28 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
21:04:01 --- quit: nj0rd (Ping timeout: 268 seconds)
21:06:07 --- quit: ALowther (Ping timeout: 264 seconds)
21:07:02 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
21:11:32 <radens> a 4
21:12:59 --- join: `Guest00000 (~user@37.113.180.34) joined #osdev
21:15:59 --- join: zeus1 (~zeus@197.239.1.32) joined #osdev
21:19:19 --- join: nj0rd (~nj0rd@i577BC039.versanet.de) joined #osdev
21:20:03 --- quit: AverageJ0e (Ping timeout: 268 seconds)
21:22:32 --- quit: zeus1 (Ping timeout: 265 seconds)
21:28:04 --- quit: absurdistani (Ping timeout: 268 seconds)
21:30:43 --- quit: bork (Ping timeout: 264 seconds)
21:30:46 --- quit: cirno_ (Remote host closed the connection)
21:31:29 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
21:31:59 --- join: bork (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
21:33:56 --- quit: drakonis (Read error: Connection reset by peer)
21:41:50 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
21:43:49 --- quit: Shikadi (Ping timeout: 260 seconds)
21:46:47 --- quit: climjark_ (Ping timeout: 248 seconds)
21:46:55 --- quit: freakazoid0223 (Ping timeout: 264 seconds)
21:48:21 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
21:48:31 --- quit: freakazoid0223 (Client Quit)
22:00:45 --- quit: cirno_ (Remote host closed the connection)
22:01:21 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
22:11:06 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:25:48 --- join: unixpickle (~alex@c-24-5-86-101.hsd1.ca.comcast.net) joined #osdev
22:30:45 --- quit: cirno_ (Remote host closed the connection)
22:31:30 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
22:34:43 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:41:27 --- quit: NaNkeen (Ping timeout: 240 seconds)
22:45:18 --- quit: lachlan_s (Quit: Connection closed for inactivity)
22:45:40 --- quit: pounce (Quit: WeeChat 2.1)
22:48:03 --- quit: X-Scale (Quit: HydraIRC -> http://www.hydrairc.com <- Po-ta-to, boil em, mash em, stick em in a stew.)
22:52:28 --- join: AverageJ0e (~joe@ip98-167-200-207.ph.ph.cox.net) joined #osdev
22:58:43 --- quit: AverageJ0e (Ping timeout: 265 seconds)
23:00:44 --- quit: cirno_ (Remote host closed the connection)
23:01:28 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
23:05:08 --- join: sdfgsdfg (~gfssa@176.33.236.80) joined #osdev
23:06:04 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
23:08:27 --- join: NaNkeen (~nankeen@203.188.234.181) joined #osdev
23:09:09 <doug16k> I setup a VM with windows 3.1. It's amusing for it to be sitting there pegging a core at 4.3GHz, doing nothing, lol
23:09:11 <doug16k> it didn't hlt
23:11:34 <sdfgsdfg> :o
23:14:30 --- join: Kelpies (~Kelpalots@ip68-102-0-77.ks.ok.cox.net) joined #osdev
23:15:44 --- join: dbittman_ (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
23:18:03 --- quit: Kelpie (Ping timeout: 255 seconds)
23:20:49 <newsham> i bet it boots really fast
23:21:31 <doug16k> yeah, and windows launches in under a second all the way to program manager (when you run "win" at DOS prompt)
23:22:17 <doug16k> maybe 100ms-200ms or so? hard to tell
23:22:33 --- quit: spare (Quit: leaving)
23:22:44 <doug16k> just imaging how many I/O accesses that would have been, lol. no DMA
23:24:24 <doug16k> 4GB drive, had to partition it into 2 2GB drives :D
23:24:35 --- quit: variable (Quit: /dev/null is full)
23:24:40 <doug16k> 2GB is max
23:24:54 <doug16k> DOS 6.22
23:28:47 <klange> anyone got any fun OSes to play with?
23:30:44 --- quit: cirno_ (Remote host closed the connection)
23:31:25 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
23:38:15 --- quit: lf94 (Ping timeout: 248 seconds)
23:41:46 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
23:48:30 <klange> i need my fix man
23:48:39 <klange> y'all got any of them... isos?
23:49:16 <bcos_> klange: https://www.reddit.com/r/osdev/comments/8jgdho/aquilaos_is_a_complete_operating_system_kernel/
23:49:17 <bslsk05> www.reddit.com: "AquilaOS is a complete Operating System (kernel + system) that is designed to be POSIX compliant and mostly ISA transparent." : osdev
23:49:49 <bcos_> (no idea if it's any good - just saw it there..)
23:50:04 --- quit: Ryanel (Quit: Leaving)
23:50:36 <klange> done aquila, manwar on the forum is behind it, nuklear port is definitely cool
23:51:50 * bcos_ can't think of anything else that's recent
23:51:52 <bcos_> :-(
23:52:17 * klange was actually waiting for manwar to release an ISO with the nuklear stuff
23:52:22 <klange> he had a few releases before that
23:54:05 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
23:58:31 --- quit: ALowther (Ping timeout: 248 seconds)
23:59:19 --- quit: jpo (Ping timeout: 240 seconds)
23:59:59 --- log: ended osdev/18.05.18