channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=24&m=7&d=12
00:03:00 <adder> wait... it can't be mapped since it's below 1M, meaning pic bad and we want absolute addresses?
00:30:00 <adder> this is it: 0x00000000001022ba: addr16 mov 0x24(%si),%eax
00:30:00 <adder> never wrote this line
00:30:00 <adder> it's a part of longmode: ...
01:33:00 * adder ragequits
02:13:00 <Mutabah> `addr16` but you mentioned long mode, are you sure that disassembly is correct?
02:13:00 <geist> that looks like an address
02:14:00 <geist> like a 64bit address to something just inside 1MB that is being interpreted as an instruction
02:14:00 <Mutabah> the address looks sensible enough for kernel code to me?
02:15:00 <Mutabah> (For early boot at least, before the jump to upper memory)
02:15:00 <geist> right
02:15:00 <geist> like an address of a function at just over 8K into 1MB, where the code may be linked to run at
04:11:00 <heat_> IMO that instruction looks super garbage
04:12:00 <heat_> probably 32-bit code interpreted as 64-bit? or vice-versa
04:12:00 <geist> well yeah it's not an instruction
04:12:00 <geist> it's an address
04:12:00 <heat_> oh haha well spotted
04:12:00 <kof673> sham1: you can chant now
04:13:00 <zid> 64 as 32 was my guess, given he said it was what was at longmode:
04:13:00 * sham1 chants
04:17:00 <zid> which turns it into mov eax, [esp-0x3d]
04:17:00 <zid> or something
04:17:00 <zid> depending what's next, I think the -3d is actually the ret
04:17:00 <zid> ye it is
04:18:00 <zid> gas says addr 16 mov eax, [si+0x24] is 67 7b 44 24, 67 7b 44 24 as amd64 is mov eax, [esp+n] with the n byte missing
04:18:00 <zid> which is exactly what you'd expect to see if he did what he said he did
04:20:00 <heat_> day 2(3?) of fucking around with a linux style page table system
04:21:00 <heat_> lots of helpers are needed, but helpers i probably could've used earlier...
05:36:00 <adder> pleased to announce that I wiped out my first attempt at writing a kernel
05:37:00 <adder> now using limine. I see gdt is loaded, so are CRs, so I suspect remap 8259, load idt, then what? What part of paging is implemented, not sure what I need to do
05:37:00 <geist> start getting interrupts working
05:37:00 <adder> sounds like a good idea
05:37:00 <Mutabah> limine likely leaves you with paging enabled, but with an identity mapping
05:38:00 <Mutabah> so you need to set up your on structures to move the kernel to upper memory and prepare for userland
05:38:00 <adder> I think I've seen they mention higher half kernel
05:39:00 <adder> https://wiki.osdev.org/Limine_Bare_Bones
05:39:00 <bslsk05> wiki.osdev.org: Just a moment...
05:39:00 <adder> "It provides cutting edge features such as 5-level paging support, 64-bit Long Mode support, and direct higher half kernel loading."
05:39:00 <geist> cutting edge!
05:39:00 <adder> :)
05:50:00 <geist> ut anyway, at this point you should decide what you want to do
05:50:00 <geist> and then work backwards from that
06:11:00 <chiselfuse> the (R)eadable bit in a code segment descriptor is ignored in Long mode. does that mean that a code segment is forced to always be readable and can't be set to be otherwise?
06:12:00 <zid> Is there a point to -R segments at all?
06:13:00 <zid> maybe as a quick hack to disable some chunk of memory in an atomic/fast way?
06:13:00 <kazinsal> not that I can think of
06:17:00 <geist> X only has some advantages, but x86 doesn't support it, no
06:17:00 <geist> riscv and arm have X only page mappings though
06:17:00 <zid> what's the point I am missing?
06:18:00 <zid> causing a fault on a slightly stray pointer is about all I can think of
06:18:00 <geist> for what?
06:18:00 <zid> -R
06:18:00 <zid> +X-R
06:19:00 <geist> yeah there's some security bits to it
06:19:00 <geist> not a giant thing, but it's sort of lie ASLR, you can make slightly more secure code if you cant even read from it
06:19:00 <geist> iirc clang or whatnot has support for it, but it's only supported on some arches
06:19:00 <zid> seems like a waste of a bit, that's incredibly weak as a protection, can't think of an exploit I've ever seen that needed it
06:20:00 <geist> zid has spoken
06:20:00 <zid> what
06:20:00 <geist> it depends on how the encoding is done really
06:20:00 <Matt|home> o\
06:20:00 <zid> why am I getting abuse for saying I think that seems pretty weak?
06:20:00 <geist> different arches decode permissions differently, so depends. riscv for example encodes page table permissions as literally RWX, 3 bits
06:20:00 <geist> so it's just one of the variants
06:20:00 <chiselfuse> what position in the descriptor would the bit have to be encoded in in order for it to be dangerous geist
06:20:00 <geist> the only one RV doesn't really support is W only
06:21:00 <geist> dangerous?
06:21:00 <zid> page table bits tend to get more and more loaded up in meanings and eventually run short, if x86 is anything to go by, they've already started stealing address bits (NX)
06:21:00 <chiselfuse> what depends on the encoding then? geist> it depends on how the encoding is done really
06:21:00 <geist> of course arm and riscv (and pretty much everything else) doesn' thave the segment descriptors anywy, so it's entirely page table perms
06:21:00 <geist> chiselfuse: oh what i mean twas how it is encoded may determine, IMO, if it's a 'waste' of a bit
06:22:00 <kazinsal> I can see --x code segments being slightly more secure than r-x code segments for kernel code if the kernel also goes through painstaking efforts to hide itself on disk
06:22:00 <geist> as in, it may just naturally fall out of the way perms are encoded, or not. in the case of X86 it doesn't really
06:22:00 <zid> You can pick a *different* encoding if you don't have to support -R though, if you added it you already wasted it
06:22:00 <chiselfuse> but point is that that all code segments are forced to be readable in longmode, right?
06:22:00 <geist> yes
06:22:00 <geist> but also remember x86 adds page table permissions on top of it
06:23:00 <zid> yea nobody actually uses segmented memory
06:23:00 <zid> you're going surprisingly deep into this
06:23:00 <geist> really the other way of looking at it is segment dscriptors in long mode are basically nerfed, permission wise. nothing interesting is done there, except to actually just determine if it's 64bit and code vs data
06:23:00 <chiselfuse> i mean, you're forced to use the permissions set in CS
06:23:00 <geist> and then all permissios really come from the page table bits
06:23:00 <geist> except, as you point out, it's forced to be R
06:23:00 <geist> because it's basically unused
06:23:00 <kazinsal> the selector itself really doesn't matter much
06:24:00 <kazinsal> there are only a handful of permutations for 64-bit selectors
06:24:00 <geist> ie, the permission bits in the long mode descriptors dont do anything, on purpose, by design. as a way of basically nerfing them to be not useful
06:24:00 <chiselfuse> geist: and if the page permission of a code segment is -R then what happens
06:24:00 <geist> ie yo uhave to load the GDT because you might load a 32bit or whatnot segment into it, but for pure 64bit you're just setting a bit pattern in the segment descriptor that says '64bit code' and that's it
06:25:00 <geist> t's probaly illegal. look at the manual
06:25:00 <geist> may be ignored, may be MBZ, i forget
06:26:00 <chiselfuse> i just wanted to know whether they're expressing the same thing or if they were orthogonal
06:26:00 <geist> or the R bit means something else for code descriptors? I honestly dont remember off the top of my head
06:26:00 <geist> this is described in the intel and amd manuals in great detail
06:27:00 <zid> bear in mind that you're forced to use 'all of memory' selectors
06:27:00 <geist> https://www.sandpile.org/x86/desc.htm yeah i guess the R bit is there. good question if you dont set it. i've never seen it not set
06:27:00 <bslsk05> www.sandpile.org: sandpile.org -- x86 architecture -- descriptors
06:27:00 <chiselfuse> geist: "The readable (R) and accessed (A) attributes in the type field are also ignored." is all in the current amd manual page i'm reading
06:27:00 <zid> so paging definitionally only applies to a subset, and has to function, so you can figure out what order things must work in
06:28:00 <kazinsal> selectors are only fun to fiddle with weird bit combinations in 16 and 32 bit modes
06:29:00 <kazinsal> I think openbsd/i386 still uses segment limits to implement W^X
06:29:00 <kazinsal> on non-NX systems
06:29:00 <geist> oh you know what, pre long mode you *can* encode a X only permission
06:29:00 <geist> looking at the intel manual now
06:29:00 <kazinsal> huh
06:29:00 <kazinsal> funny that they didn't carry that over
06:29:00 <geist> 0 0 0 for C R A seems to be execute only
06:29:00 <zid> yea, that's where we started, R is ignored in long mode, does that mean everything is +R
06:30:00 <chiselfuse> geist: that holds for long mode too
06:30:00 <chiselfuse> i think...
06:30:00 <chiselfuse> no wait nvm i'm confusing things
06:31:00 <geist> the intel manual seems to very confusingly present this
06:31:00 <geist> it basically says here's all the bits, oh and also if uo're in ia32e mode L means long mode
06:32:00 <geist> so the AMD manual says very clear what's going on
06:33:00 <geist> https://usercontent.irccloud-cdn.com/file/Dl2cXcnL/image.png
06:33:00 <zid> intel manual we found also refuses to acknowledge fsbase, the only actual mention of it is in the tss psuedocode for a task gate I think, I discovered earlier
06:33:00 <geist> thsi is a case where the AMD manual > intel manual
06:33:00 <zid> for saving it
06:33:00 <geist> so that straight up answers it: R is ignored
06:33:00 <kazinsal> yep I'd trust the verdict of the amd manual here
06:33:00 <chiselfuse> geist: the info of whether a segment is "execute" seems to come from whether it is pointed to by CS or otherwise
06:33:00 <zid> well code fetches happen through cs
06:34:00 <zid> so anything cs can access, is not a #GP
06:34:00 <kazinsal> also bit 11 needs to be set for it to be a code descriptor
06:34:00 <kazinsal> so consider that your X bit
06:34:00 <kazinsal> or is it 10
06:34:00 <zid> if your cs were -x it would fault 100% of the time, seems like one of those things they'd make #GP just for trying to load it
06:34:00 <geist> i thin it's 11
06:34:00 <geist> the C bit is 'conforming' which means something i forget
06:34:00 <chiselfuse> C and R become E and W for non-code segment descriptors
06:35:00 <kazinsal> soemthing about cross-RPL calls
06:35:00 <kazinsal> I think
06:35:00 <kazinsal> can't remember how it works
06:35:00 <geist> yah
06:35:00 <zid> conforming means you can run them at the 'wrong' priv level, afaik
06:35:00 <kazinsal> because descriptors have been pretty much set and forget since the 386
06:36:00 <zid> I think it's designed for like, vdso type stuff
06:36:00 <kazinsal> apart from aforementioned weirdness like openbsd/i386 setting up new user mode base/limits on context switches
06:36:00 <chiselfuse> Conforming (C) Bit. Bit 10 of the upper doubleword. Setting this bit to 1 identifies the code segment as conforming. When control is transferred to a higher-privilege conforming code-segment (C=1) from a lower-privilege code segment, the processor CPL does not change. Transfers to non-conforming code-segments (C = 0) with a higher privilege-level than the CPL can occur only through gate descriptors.
06:36:00 <geist> the key was before all of this, bit 21 was unused. and so they had one bit left, and they turend that into the L bit
06:36:00 <chiselfuse> See “Control-Transfer Privilege Checks” on page 109 for more information on conforming and non-conforming code-segments.
06:36:00 <kazinsal> 16-bit protected mode code tended to make fairly heavy use of LDTs
06:37:00 <kazinsal> on account of only having sixteen bits of virtual address space to work with
06:39:00 <geist> i've always found the AMD manual is more clear with all this stuff. the intel manual tends to be written in the order the cpus were released, so it'll talk aabout all the stuff for 286, then 386, then say 'oh and then there's this long mode that modifies everything you just read'
06:39:00 <geist> like they didn't go back and re-edit the thnig
06:39:00 <kazinsal> yeah
06:39:00 <geist> whereas the AMD manual tends to present it all as one thing, so it's a bit more cohesive
06:39:00 <zid> yea intel manual needs a good cleanup, but that's a hard sell internally I imagine
06:40:00 <kazinsal> they can't figure out how to fab chips that don't spontaneously combust. their documentation team probably got fired a decade ago
06:40:00 <kazinsal> the high end raptor lake chips are nearing recall territory
06:40:00 <geist> yah ive been reading intel mauals for nearly 30 years now and it really hasn't changed much, just more stuff added
06:40:00 <geist> no real rewrites. my old 1996 pentium pro manual has basically the same text just minus new stuff
06:43:00 <kazinsal> the pre-pentium manuals are good fun to read
06:43:00 <kazinsal> I've got the 80386 one around here somewhere and it's extremely detailed
06:43:00 <geist> yeah same
06:43:00 <geist> got it used off amazon
06:43:00 <chiselfuse> kazinsal: can you give me the exact title of this 80386 one?
06:44:00 <chiselfuse> how is it different than the regular intel manuals?
06:44:00 <kazinsal> I'd have to go find it but it differs on account of being almost 40 years old
06:45:00 <kazinsal> Intel 80386 Programmer's Reference Manual
06:45:00 <kazinsal> documentation ID 230985-001
06:45:00 <geist> https://usercontent.irccloud-cdn.com/file/CpTFhLSp/image.png
06:45:00 <geist> yeah pretty similar here
06:46:00 <geist> this is 230985-003
06:46:00 <kazinsal> oho, I haven't seen that one
06:46:00 <kazinsal> yours is newer
06:46:00 <kazinsal> my physical copy is on my desk at work
06:46:00 <kazinsal> but I have a PDF copy here as well
06:46:00 <geist> only slightly, looks like 1990
06:46:00 <kazinsal> I have a number of job-irrelevant books at the office so no one tries to use my desk as a hot desk
06:47:00 <chiselfuse> kazinsal: do you use it for your job?
06:47:00 <chiselfuse> oh i just read last message
06:47:00 <kazinsal> both the windows internals 7th edition books, both volumes of Routing TCP/IP by cisco press
06:47:00 <kazinsal> it's just for show mostly
06:47:00 <chiselfuse> hacker desk
06:47:00 <kazinsal> I work for a university so we have some co-op students who are in more frequently than I am
06:48:00 <geist> yah sae, i have the VAX manual here, kinda a show off
06:48:00 <geist> though it doesn't really work, because no one has the faintest clue what a vax is
06:48:00 <kazinsal> and if you don't thoroughly display your ownership of the desk they'll end up using it to reflash a bunch of laptops
06:48:00 <kazinsal> so there's books and a couple framed photos and a yeti tumbler
06:48:00 <kazinsal> and a big fuckoff sign that says TROY MARTIN | SENIOR SYSTEM ADMINISTRATOR
06:49:00 <geist> haha yeah, if you dot cover your desk someone assumes it's not in use
06:49:00 <kazinsal> though this wednesday one of my colleagues came in after taking two weeks off and found someone had fucked with his chair... despite one of his framed things on his desk being a 25-year service award
06:49:00 <Mutabah> Three plushies, two minis, and three old cameras :D
06:50:00 <chiselfuse> what did they do to the chair
06:50:00 <kazinsal> messed with the lumbar or something
06:50:00 <geist> or someone messes with your monitor, i hate that
06:50:00 <geist> i have it just so
06:50:00 <kazinsal> oh yeah
06:50:00 <kazinsal> I wrote down the colour calibration numbers for my monitors at the office
06:50:00 <kazinsal> just so no one can mess with them
06:51:00 <chiselfuse> i'd just put a very thin wire all over the desk edges and connect it to low current supply tbh. ornamenting the thing with stuff that collects dust and gives you a sense of disorder just to deter people meh
06:51:00 <kazinsal> even with the union I think I'd get fired for that
06:53:00 <chiselfuse> kazinsal: not if you explain to them that the wire is there for ornament and that it coincidentally happens to touch the computer case externally which happens not to be grounded properly which overall you cba to fix
06:54:00 <geist> no you cant electrocute your cow-orkers
06:55:00 <geist> that'll get you a chat with HR
06:56:00 <kazinsal> plus I don't want to trouble my shop steward. she's nice and it'd be like an hour drive to the campus my office is at
15:32:00 <xtex> shortly after STI, I am getting an interrupt 8 without error code. Where is it from?
15:33:00 <heat> you didn't remap your PIC
15:34:00 <dostoyevsky2> Why are people still writing 32bit OSes? Is x64 such a drag?
15:34:00 <GeDaMo> Maybe they're targeting older hardware
15:34:00 <heat> x86-64 is hard to start off with, because of the mandatory paging
15:34:00 <xtex> oh I am looking into PIC remapping. Thanks
15:34:00 <dostoyevsky2> heat: yeah, that could be it...
15:35:00 <heat> 32-bit is a lot more dumbed down to start with. once you get into paging it's roughly equal, but you have a nicer environment to debug with
15:35:00 <dostoyevsky2> https://github.com/jart/sectorlisp <- I guess that would be much larger in x64
15:35:00 <bslsk05> jart/sectorlisp - Bootstrapping LISP in a Boot Sector (55 forks/1199 stargazers/ISC)
15:35:00 <heat> whereas in x86_64 it's virtually "write a bunch of paging code with no output, no way to debug, usually in assembly"
15:42:00 <dostoyevsky2> heat: Couldn't one just use the setup some popular OpenSource OS uses and be done with it?
15:43:00 <heat> nope
15:44:00 <heat> e.g linux's setup is incredibly complex and full of crap most people don't need
15:44:00 <heat> they even execute a lot of C code (while running at the wrong address)
15:50:00 <Ermine> crap as in "you don't need it while writing your own os" or crap as in "it can be improved even in the context of linux"?
15:51:00 <dostoyevsky2> https://github.com/duqi007/linux-kernel-2.5/blob/master/arch/x86_64/boot/bootsect.S <- doesn't look too complicated to me... 500 LoC and you probably can leave away the things you don't need
15:51:00 <bslsk05> github.com: linux-kernel-2.5/arch/x86_64/boot/bootsect.S at master · duqi007/linux-kernel-2.5 · GitHub
15:57:00 <heat> Ermine, you don't need it
15:57:00 <netbsduser> dostoyevsky2: this is why i went for limine
15:57:00 <heat> dostoyevsky2, haha 1) linux 2.5 2) the boot sector is a very small part of the boot code
15:57:00 <netbsduser> i like the amd64 on the whole but i don't care much for getting myself into a sensible state on it
15:58:00 <heat> x86_64 linux has some 3 or 4 separate boot paths for commodity hardware, depending on the setup
15:58:00 <netbsduser> i think 32-bit x86 is targeted mostly because old tutorials (often of dubious quality) target it
15:58:00 <heat> i would not target x86_64 on a new tutorial
15:59:00 <netbsduser> why not? riscv and aarch64 are minefields of proprietary specificities
15:59:00 <heat> paging is such a brilliant hard to understand thing that starting off with "hey lets decode this 4 level maybe 5 level complex structure that transparently transforms your memory accesses"
16:00:00 <dostoyevsky2> netbsduser: Ah, limine is interesting
16:00:00 <dostoyevsky2> https://github.com/limine-bootloader/limine
16:00:00 <bslsk05> limine-bootloader/limine - Modern, advanced, portable, multiprotocol bootloader and boot manager. (134 forks/1685 stargazers/BSD-2-Clause)
16:00:00 <heat> riscv and aarch64 at least have the property of actually supporting nommu
16:01:00 <heat> you can boot at your own pace
16:01:00 <netbsduser> if i can't have an MMU i don't want it
16:01:00 <heat> meanwhile in x86_64 part 0 needs to be a speedrun on the x86 architecture up to 2001
16:01:00 <netbsduser> my kernel started as the support code for an implementation of what's described in the mach vm paper
16:02:00 <heat> paging, gdt, possibly a dummy idt (all in 32-bit assembly ofc), poking msrs, doing a complicated dance using cr0 and cr3, switching processor modes, reloading a new gdt, and finally fucking jumping to C
16:03:00 <netbsduser> this is why i opted for limine to avoid that
16:03:00 <heat> you could write most of the above in C, but that falls into the dark arts of writing position-independent C using gcc/clang
16:18:00 <dostoyevsky2> netbsduser: isn't there something like a minimal x64 bootloader? I see limine also has a boot menu, which is great, but also kind of makes it hard to see the essential parts
17:48:00 <chiselfuse> i learned that every memory access (even RIP) happens through segmentation on x86. what segment does `mov [rbp+0x8], rax` use? it puts the value of `rax` into the memory location pointed to by address calculated by: <base address of some segment> + rbp + 0x8. in long mode, what segment is it?
17:48:00 <Ermine> so it's not necessary to do paging on aarch64?
17:49:00 <GeDaMo> chiselfuse: in 64 bit mode, segments aren't really a thing
17:49:00 <heat> Ermine, no, not strictly required. but required if you want to e.g get caching
17:49:00 <GeDaMo> Only fs and gs have uses, all the others are based at 0 and cover all of memory
17:50:00 <chiselfuse> GeDaMo: they are though, even RIP is really CS:RIP even though its base address is always 0
17:51:00 <chiselfuse> GeDaMo: AFAIU the CS in CS:RIP is still relevant because there are some flags that can change in its segment selector
17:51:00 <GeDaMo> I'm pretty sure that mov will use ds by default
17:51:00 <chiselfuse> GeDaMo: i just want to know which segment register that instruction i posted uses
17:51:00 <chiselfuse> hmm
17:51:00 <Ermine> chiselfuse: CS:RIP = RIP if base is 0
17:51:00 <Ermine> for data accesses it's DS
17:52:00 <chiselfuse> not SS? since rbp is used for stack
17:52:00 <Ermine> or SS... idk
17:53:00 <heat> it really doesnt matter
17:53:00 <Ermine> ^
17:53:00 <Ermine> your base is 0
17:53:00 <heat> SS = DS = ES = CS in x86_64
17:53:00 <gog> the only segments whose bases are relevant in long mod are FS and GS
17:54:00 <gog> and even then we have instructions to deal with those indirectly now
17:54:00 <GeDaMo> I said that! :P
17:54:00 <gog> oh hi GeDaMo
17:54:00 <gog> :D
17:54:00 <chiselfuse> heat: and yet the manual makes a distinction between segment descriptors of code segments vs data segments for long mode
17:54:00 <gog> so you did
17:54:00 <chiselfuse> i don't care about base address
17:54:00 <heat> yes it does
17:54:00 <heat> you can't execute when cs = a data segment
17:54:00 <chiselfuse> i know it's all zero except for fs and gs
17:54:00 <heat> that's literally the only difference
17:55:00 <heat> nothing else matters
17:55:00 <Ermine> so you set proper selectors in ds and cs and that's all
17:56:00 <Ermine> the fact that x86(_64) is a mess is not news
17:56:00 <chiselfuse> what's the harm in knowing what the cpu uses for `mov [rbp+0x8], rax` even if it doesn't matter
17:57:00 <heat> rbp uses ss
17:57:00 <GeDaMo> 8086 asm reference, bottom of page shows default segments https://archive.org/details/bitsavers_intel80869yLanguageReferenceGuideOct78_5061675/page/n4/mode/1up
17:57:00 <Ermine> ther's no harm, but there's no use in that
17:58:00 <Ermine> I always tend to just forget such details
18:06:00 <GeDaMo> All your bases are belong to zero! :P
19:56:00 * geist yawns
19:58:00 <heat> geist!
19:58:00 <geist> heat
19:58:00 <heat> whats updog
20:05:00 <geist> no tmuch. it's a friday.
20:05:00 <geist> and uh, nice weather
20:05:00 <kazinsal> meetings day
20:06:00 <Ermine> hi
20:12:00 <heat> i found a dumb problem on my OS where i never invalidated the tlb when page faulting
20:13:00 <geist> ru roh that'll do it
20:14:00 <heat> it's not really a reproduceable problem
20:15:00 <heat> i just found it independently. probably because most programs i run are single threaded
20:15:00 <heat> the big problem would be that you could observe stale data
20:20:00 <geist> yeah sounds lje yiou need to write some directed testing that tries to incover this sort of thing
20:22:00 <dinkelhacker> Can you do (relative) performance testing with qemu?
20:22:00 <heat> with kvm totally
20:23:00 <dinkelhacker> but that would mean only for my host architecture, right?
20:24:00 <heat> yep
20:24:00 <kazinsal> cross-arch performance testing is Complicated
20:25:00 <dinkelhacker> hm and without would you say it is complete bs or could you still see if something performs better than another thing?
20:25:00 <heat> your performance will in no way mirror a real CPU
20:25:00 <heat> well, in no *guaranteed* way
20:26:00 <dinkelhacker> that would be fine as long as it would mean that i could still see if something is twice as fast... But i guess I can't be sure?
20:27:00 <heat> i'd say it heavily depends on what you're doing
20:27:00 <heat> like going from O(n) to O(1) will be visible in qemu tcg
20:28:00 <heat> but, depending on how tcg does codegen, going from a linked list to a std::vector might not
20:30:00 <heat> also AFAIK qemu tcg multi core is kind of iffy
20:31:00 <dinkelhacker> Hm... That kind of expected this answer. Guess I'll have to buy some hardware.
20:34:00 <dinkelhacker> heat: thx!
20:41:00 <geist> yah +1 to what heat said
21:08:00 <nikolapdp> heat what do you mean `kind of iffy`
21:09:00 <geist> how qemu emulates multi core is version and arch specific, for one thing
21:09:00 <geist> some combinations of versions and arches, its actually only running a single host thread and round robining bertween emulated cpus, for example, which would completely screw up any sort of benchmarking
21:10:00 <geist> it's possible that may no longer be the case in current tip of tree qemu for all arches, but i honestly dunno
21:11:00 <nikolapdp> huh interesting
21:11:00 <heat> yeah, also i've heard of weird stalls/performance problems on multi-cored qemu tcg vms that were *solved* by forcing single thread
21:11:00 <geist> even if it's running full multitread there are a lot of cases where the host threads have to synchronize
21:12:00 <geist> TLB shootdowns cross core, etc
21:12:00 <geist> or some atomic stuff, depending o the combination of host and target
21:13:00 <zid> chiselfuse: We had someone at some point with a fun bug where certain lines of C were doing the complete wrong thing for some reason
21:13:00 <zid> mainly seemed to be weirdness with passing parameters
21:14:00 <zid> turned out their ds and ss were different, so push eax; and mov [stack], eax were giving different results
21:18:00 <nikolapdp> heh nice
21:18:00 <gog> oops
21:20:00 <zid> nikolapdp is it monday yet
21:20:00 <nikolapdp> no
21:20:00 <zid> fuk
21:23:00 <gog> just another manic monday
21:24:00 <gog> wish it was sunday
21:24:00 <gog> 'cause that's my funday
21:24:00 <gog> my i-don't-have-to-run-day
21:26:00 <zid> why would you run on any day
21:26:00 <zid> I wouldn't run even if there was lava coming at me
21:28:00 <heat> gog do you have that dawg in you
21:28:00 <heat> i think you clearly don't because dawgs love running
21:29:00 <gog> why must i be like that why must i chase the cat
21:29:00 <gog> nothin but the dawg in me
21:30:00 <netbsduser> i couldn't forget about tlb flushing, it's incredible how slow things are with a few cores under qemu amd64 when i give little memory (which i do as standard to exercise page replacement and give me early indication of something going awry there)
21:30:00 <gog> did i tell you i was sining atomic dawg or something
21:30:00 <netbsduser> the m68k port is blazing fast by comparison
21:32:00 <heat> wow little memory?
21:32:00 <heat> how*
21:32:00 <Ermine> sawg
21:32:00 <Ermine> dawg
21:32:00 <netbsduser> 6m on m68k, 14 amd64
21:33:00 <netbsduser> about the minimum with which i can boot and load a program
21:33:00 <heat> that's tight
21:37:00 <netbsduser> it should be possible to tighten it further, i am checking now and only about 950 pages of kernel wired memory are used on m68k to boot and run a program which spawns a few threads and loops forever
21:39:00 <netbsduser> about half of which are the virtio-gpu framebuffer, but we can exclude those from the count
21:40:00 <heat> i need 4.4M file (swappable) + 1.1M anon (not yet swappable) + 4.4M slab (not swappable) + ~200K page table (not swappable)
21:40:00 <heat> plus whatever weird random page allocations i have that i'm not accounting for
21:41:00 <heat> somehow adds up to 20M
21:41:00 <netbsduser> it looks like the bare minimum i can have on m68k is 175 pages if i want boot to not proceed at a literally glacial pace and to frequently trip areas where i don't yet handle physical page shortage properly
21:42:00 <heat> <6>[ 4.513733] kmalloc-131072 131072 size 0 full 0 free 1 partial 1 active objs 131072 total obj size ~1052672 total slab size
21:42:00 <heat> gotta love these one-off allocations
21:45:00 <netbsduser> when i start getting things to web scale levels (slab magazines and so on) i expect to be requiring a bit more memory on smp systems
21:47:00 <heat> but will you run mongodb??
21:52:00 <netbsduser> of course i will
21:52:00 <netbsduser> it is web scale
21:54:00 <heat> day 3 of linux-like page table styling: *lots* of wrappers, but the promise of avoiding duplicating tricky logic is still very enticing to me
21:58:00 <netbsduser> what are you plotting
21:58:00 <netbsduser> i also moved over to a linuxish approach to the page tables
21:58:00 <netbsduser> that makes a vax port trickier unfortunately but swings and roundabouts
21:59:00 <heat> i want to remove my pmap duplication across archs by having a unified page table scheme (with pgd_t, p4d_t, pud_t, etc)
21:59:00 <heat> end goal is to also remove the amaps and store anon memory/swap info directly in page tables
22:01:00 <netbsduser> i had similar goals
22:02:00 <netbsduser> the only particular annoyance was the 68040 MMU has page tables not page sized and i like to allocate those in multiples to make up a page's worth
22:06:00 <heat> is that work on your master branch?
22:07:00 <heat> oh, tables.c probably
22:47:00 <chiselfuse> zid> turned out their ds and ss were different, so push eax; and mov [stack], eax were giving different results
22:47:00 <chiselfuse> but `push eax` means "put eax in ss:rsp and decrement rsp", `mov [rsp], eax` means "put eax in ss:rsp"... both use `ss` implicitly, not `ds`. can you clarify?
23:35:00 <geist> the default segment register for *bp and *sp is ss, everything else is ds
23:35:00 <geist> just one of those weird quirks