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=11&d=3
01:25:25 <pZombie> hello friends
01:27:46 <pZombie> Can someone clarify hyperthreading a little bit? When a CPU has hyperthreading enabled, with 8 physical cores, then some people saying that this CPU has 8 physical and 8 virtual cores is accurate? It does not seem to make sense
01:28:16 <Mutabah> if HT is enabled, there's (usually) two logical/virtual cores per physical core
01:28:22 <ybyourmom> Hyperthreading is an optimization where the processor presents extra sinks as if they were another CPU
01:29:07 <ybyourmom> The hyperthreading logical CPUs are "virtual" in an absolute sense but to the OS they appear to be an independent execution resource
01:29:52 <pZombie> Mutabah, yes, i was about to say that. Each core has two IPCs which the OS shows as two virtual/logical cores
01:32:23 <pZombie> however, since those virtual cores add considerable overheat, if you were playing a game that only uses 4 cores, and you have a 6 or 8 core CPU, you should fare better turning HT off
01:32:43 <pZombie> overhead*
01:33:03 <ybyourmom> No, it's not about overhead; it's about contention
01:33:16 <pZombie> can you elaborate?
01:33:16 <ybyourmom> And it
01:34:16 <ybyourmom> Hyperthreading attempts to use unallocated processing sinks more efficiently by presenting them as if they are part of a separate CPU altogether
01:34:57 <ybyourmom> So if the CPU has 16 adder units, and only 8 of them are used on average, then the CPU can pretend it is two CPUs and present the other 8 adders as if they are another CPU altogether
01:35:33 <ybyourmom> When you begin to actually stress the CPU with a hard workload, the "real" CPU begins to schedule more operations to the redundant execution resources
01:35:44 <ybyourmom> And the "pretend" CPU begins to get starved; or vice versa
01:35:49 <ybyourmom> It's a contention issue
01:36:05 <pZombie> they are all pretend CPUs when HT is on
01:36:10 <pZombie> logical cores
01:36:16 <pZombie> but i get your point
01:36:20 <ybyourmom> You can think of it that way
01:38:34 <pZombie> basically, the operating system and or the game is too stupid to tell the single cpu core to NOT share resources between the two logical cores when there are enough other cores available
01:38:45 <pZombie> to do the job
01:40:21 <pZombie> resulting in some games showing a significant drop in FPS when HT is on, vs off
01:40:54 <pZombie> except on CPUs with 2 physical cores and HT, in which case you almost always see an about 50-60% fps increase, given you have enough GPU power to back it up
01:41:07 <pZombie> and the game you play uses 3 or more cores
01:42:29 <pZombie> which makes sense, as from what i have seen, a fully utilized CPU with HT enabled give you an about 50-60% performance increase in applications which make the max use of the cores
01:44:33 <chrisf> by 'max use', i assume you're just meaning 'runs enough threads to light them all up'
01:44:43 <pZombie> yes
01:44:58 <chrisf> lots of threads of garbage code gets a solid benefit
01:46:13 <pZombie> i mean, HT is not just some virtual stuff as far as i can tell. There is actual extra hardware on CPUs with HT. For example, a physical core having two Instruction Point Counters rather than just one
01:46:24 <pZombie> that has to account for some extra performance
01:46:42 <Mutabah> The core has two entire register banks
01:46:46 <ybyourmom> x86 processors have very large register files
01:47:05 <ybyourmom> And they make extensive use of register renaming
01:47:22 <pZombie> Mutabah, if you turn HT off, does the core turn off the second register bank?
01:47:35 <Mutabah> I think so
01:47:39 <ybyourmom> When HT is turned on, a portion of the register file being divided off to the other hyperthread isn't a big deal
01:47:53 <aalm> i would guess there's SMT-aware schedulers, if HT makes your gaming experience worse, it might not be running w/such..
01:48:54 <pZombie> aalm - I don'T know the details, which is why i said Operating system and or Game not handling it properly, but yes, it is a software issue if your game drops in fps with HT off, not a hardware one
01:49:38 <pZombie> roughly speaking i guess
01:49:59 <pZombie> because i am not sure if HT on adds some extra system latency vs HT off. I think it does
01:50:03 <ybyourmom> The tradeoff for games in querying CPU topology and attempting to bind their threads using affinity to specific CPUs based on how they they *think* the CPU is scheduling its sinks is too high
01:50:41 <ybyourmom> And it's impossible for software to make objective optimizations since they don't have enough information about the amounts of execution resources available on the CPU they're trying to schedule for
01:51:19 <ybyourmom> So it's not a software problem; Intel doesn't publish information about the number of redundant units on their CPUs, the number of each type of unit, etc
01:51:29 <ybyourmom> So it's not possible for software to optimiz
01:53:07 <pZombie> but the operating system has the information, doesn't it? Properly programmed, the operating system should be able to prevent any game from running better with HT off rather than HT on
01:53:27 <ybyourmom> The OS doesn't know the CPU's allocation strategy for sink units on the die
01:53:48 <ybyourmom> It gets topology information as far as cache topology and CPU topology
01:54:05 <ybyourmom> Not as far as percentage allocation of sinks per hyperthread
01:54:53 <pZombie> hm, interesting
01:55:07 <Mutabah> That... and HT perormance depends on the fine-grained workloads
01:55:30 <Mutabah> e.g. when there's memory contention, HT can reallt speed things up (because the core itself is not being used much)
01:56:03 <Mutabah> but e.g. if you have a lot of FPU usage, HT might not speed thigs up much (might even be slower) because each core usually only has one FPU
01:56:20 <clever> i think the best you can really do from software, is to just set some thread affinity, and then run benchmarks, and see what cores have some effect on what other cores
01:56:47 <dormito> lol
01:56:55 <clever> but ive also heard that the bios/cpu may remap the core numbers on every powerup, so the effects you detect might change with every reboot
01:57:22 <dormito> clever: linux knows which cores are paired off. iirc /proc/cpuinfo will tell you as well
01:58:18 <dormito> I suspect the ACPI tables also mark which cores share which resources (L1 $, L2$, etc)
01:58:28 <pZombie> i think windows knows as well which cores are paired, going by the built in cpu monitor
01:58:34 <dormito> I know that information is used to make scheduling decisions
01:58:36 <chrisf> where is this "usually only has one FPU" thing coming from?
01:58:49 <clever> [root@system76:~]# grep 'core id' /proc/cpuinfo
01:59:03 <clever> my laptop is showing 0123 0123
01:59:20 <clever> desktop just shows 01234567
01:59:33 <dormito> chrisf: probably a missnomber. some AMD systems did share an 'FPU' between cores... but its... complex
02:00:22 <pZombie> dormito - we are talking FPU per physical core, shared by the two logical cores of that physical core... i believe
02:01:06 <dormito> if you wanna know more about technical details o 'hyperthreading' I suggest you look up SMT/symettric multi threading. which is what HyperThreading is an implementation of
02:03:35 <chrisf> even bulldozer has multiple float pipelines in their shared fpu block
02:04:07 <pZombie> i am just not sure why they did not just add more physical cores without any HT. I thought most cost in CPUs is development rather than material costs
02:04:28 <ybyourmom> Space weight and power
02:04:45 <dormito> pZombie: the extra gates to add an SMT implementation are insignificat compred to that of the core
02:04:45 <chrisf> pZombie: most real world code has garbage IPC.
02:05:29 <ybyourmom> If you can extract more parallelism(power) from the existing chip while not having to add more physical hardware (same price), why not squeeze that extra power out?
02:05:50 <ybyourmom> It's a win win for your customers
02:06:16 <dormito> SMT is a hw change, but it's a small one compared to adding more cores to the die
02:06:27 <clever> ive also heard, that for compute jobs that are not aware of the number of FPU elements and such, HT can improve performance
02:06:41 <clever> and that also includes multiple unrelated loads that are not maxing out the FPU elements
02:06:47 <pZombie> because the price for the material is insignificant compared to the price you sell the CPU at is what i imagined. The price of CPUs mostly reflects the development cost + greed
02:07:08 <clever> but if you compile something properly, for that exact cpu, and can push it to its limits, HT will start to harm performance
02:07:25 <ybyourmom> pZombie: Prices convey underlying cost and value
02:07:47 <clever> but that code will likely also perform worse on any other chip, so you must now manage a seperate binary (or at least a list of variations of the same function) for every cpu you want to work really fast on
02:08:36 <ybyourmom> Saying that increasing price convey greed is like saying that since prices of land increase as you move toward the coast, that must mean that living in a coastal area enflames greed
02:08:54 <ybyourmom> Prices are not arbitrary
02:10:26 <pZombie> clever - but HT gives you an extra IPC and extra registers according to Mutabah. This to me suggests that if your software can make use of all those extra resources, it would ALWAYS run better on HT enabled CPUs, no matter how perfect you program it
02:11:44 <ybyourmom> HT increases parallel usage of the cpu's sinks. If you have two workloads that are dissimilar enough that they rarely contend for the same sinks, then HT will give you an almost 100% performance boost in that case
02:13:05 <bcos_> pZombie: CPUs stall all the time (due to branch mispredictions, cache misses, dependencies, ...), so the basic idea of HT is to do useful work (for another CPU) instead of doing nothing. However, software rarely scales perfectly (twice as many CPUs is never twice as much performance due to Amdahl's law, locks, etc) so when there's not many stalls and bad scalability it ends up worse
02:13:14 <pZombie> ybyourmom, that makes sense, but does HT also add more registers as Mutabah suggested, or does it just turn a set of the same physical registers into two sets of logical registers?
02:13:38 <ybyourmom> That is, as ARM would say, [ Implementation defined ]
02:13:59 <pZombie> what about standard intel/amd desktop CPUs then?
02:14:23 <dormito> pZombie: HyperThreading is an intel only thing (It's their branding of SMT)
02:14:24 <ybyourmom> Since Intel doesn't publish this information, you'd have to ask an Intel engineer I'm afraid
02:14:43 <pZombie> i see
02:14:46 <bcos_> pZombie: Modern CPUs have "architectural registers" (what software sees) and "internal registers" (what the CPU actually uses); plus a pile of logic to assign one to the other (register renaming, etc). HT is like giving existing internal registers a different name
02:15:17 <ybyourmom> They most likely just divide up the register file, as bcos_ points out
02:16:01 <dormito> well, it's not like they have anywhere else to store the contents of the registers
02:17:02 <pZombie> since register memory is very expensive, i would think that they just turn the physical registers into two logical register sets... and gain some performance in software which rarely uses all registers at the same time
02:18:04 <pZombie> they might even use a different register than what the logical core demands if it is interchangable
02:18:10 <klys> except this is all conjecture, as none of us really know the size of register memory in the ALU.
02:18:11 <pZombie> interchangeable
02:19:44 <chrisf> well, let's pick a random machine. haswell's physical register file per core is 168 integer registers and 168 float registers.
02:20:19 <pZombie> so yeah, if they just visualize the physical registers and there isn't actually two sets with HT on, then you would gain very little if your software would be programmed in a way to make full use of them, rather than have the CPU fix your sloppy programming
02:20:36 <pZombie> virtualize*
02:21:03 <klys> I could tell you it's composed of latches and shift registers, just not how many shift registers are in there.
02:21:29 <lsneff> Well, I got the offer from microsoft
02:22:03 <bcos_> pZombie: Can you predict the future and tell me when an IRQ will occur, so I can write software "programmed in a way to make full use of"..?
02:23:16 <pZombie> you could write software which does not require an operating system
02:23:23 <pZombie> then you should be able to predict the future
02:23:26 <bcos_> ..keeping all parts of a CPU busy at the same time is a mixture of "impossible" and "impractical"
02:24:30 <dormito> lol. bcos_ and furthermore , in x86's case the rest of the register file is invisible to software
02:25:12 <pZombie> damn, those modern CPUs really like to hide stuff
02:25:39 <chrisf> your job is to express "enough" parallelism and not shoot the machine in the foot
02:26:04 <lsneff> I'm not sure if I should take it though
02:26:15 <ybyourmom> lsneff: do you have a better offer?
02:26:51 <lsneff> I have offers/will-soon-be-offers working on stuff that I know will be interesting to me
02:26:57 <lsneff> I don't know what I'd be doing at microsoft
02:27:21 <ybyourmom> Ah, well, working on something you are interested in really improves your quality of life and the quality of your work
02:27:29 <ybyourmom> So I'd take the interesting stuff then
02:27:41 <ybyourmom> but YMMV
02:28:36 <lsneff> It's just for a few months, so I should probably just deal with it
02:29:08 <ybyourmom> Sure, adding "Microsoft" to your resume is strategically shrewd
02:29:51 <lsneff> Especially as a freshman, yeah
02:30:10 <pZombie> more important is that you get to know different work environments
02:31:25 <lsneff> Would it be best to take this offer now, and then explore startups/etc in the future then?
02:31:34 <pZombie> unless you would have to sign something which would hinder future switching to a different work environment
02:31:50 <pZombie> or your performance within a future environment
02:32:39 <pZombie> i am just brainstorming. I have no clue how this works
02:33:03 <lsneff> Yeah, I don't think any ndas/etc would extend outside of the internship
02:33:55 <pZombie> while i don't know how this works, i think you should definitely know for sure before you sign anything
02:34:39 <lsneff> I'll definitely read all of the fine print.
02:36:54 <lsneff> This isn't to say that the microsoft internship won't be fun
02:36:56 <lsneff> it would be
02:37:18 <lsneff> But I most likely wouldn't be working on compilers and operating systems, like I would be elsewhere.
02:41:48 <klys> what's the simple kernel? I seem to recall hearing about a simple os with acpi support.
02:46:30 <pZombie> is it possible to write self modifying assembly code with modern CPUs still, or has the RAM mapping been virtualized too?
02:47:13 <pZombie> real self modifying as in overwriting the code at a given physical RAM address
02:47:14 <klys> yes, it's possible. just you may have to adjust for things to appear at a different cpu's cache.
02:48:09 <pZombie> what has the cpu cache have to do with it?
02:48:15 <pZombie> does*
02:48:58 <klys> smp is symmetric multi proccessing. you have a different cpu working on the same region, you may need to flush your tlb.
02:51:06 <pZombie> strange, i remember some guy in #asm telling me that with modern CPUs there is no performance gain by going with self modifying code but i don't remember the exact reason.
02:51:13 <Mutabah> That, and some CPUs have split I and D caches
02:51:20 <Mutabah> Oh yeah, no performance gain, but you can do it
02:51:33 <Mutabah> (It's probably a performance loss, because modifying the active code leads to a ichache flush)
02:52:45 <pZombie> i was thinking some kind of evolutionary AI, which randomly modifies its own assembly code
02:54:20 <ybyourmom> Consciousness can be effectively modeled as an infinite loop where on each iteration of the loop, the program attempts to execute actions that will ensure that it reaches the next iteration of the loop successfully (survives)
02:54:59 <ybyourmom> And higher consciousness can be modeled as attempted to add the ability for the loop to try to anticipate future risks to it reaching the next iteration and prepare for them beforehand
02:55:12 <ybyourmom> Doesn't require self modifying code imo
02:55:43 <pZombie> i am not sure what you described there, but it certainly wasn't consciousness
02:57:04 <pZombie> you described a mechanical process
02:57:28 <pZombie> deterministic too, given the same input data, you get the same behavior
02:57:40 <klys> mechanical processes are rarely turing-complete.
02:57:57 <pZombie> why you had to call this conscious, rather than just some complex mechanism is beyond me
02:58:29 <bcos_> pZombie: Can you prove consciousness isn't a deterministic mechanical process?
02:58:48 <aalm> :]
02:59:22 <klys> much more likely it is an electronic process. mechanical processes rely on too many factors to be clockwork.
02:59:31 <pZombie> that's like asking if i can prove if an apple isn't a deterministic mechanical process.
02:59:48 <pZombie> one is an apple, the other is a deterministic mechanical process
03:00:53 <pZombie> now if you want to go on and find a single word for what a deterministic mechanical process is, be my guest, but please use some new word, like kaboozaza rather than consciousness
03:01:14 <klys> the process of choosing which environmental factors to rely on, is largely a matter of experience.
03:04:22 <aalm> AI doing something randomly is no different, that it does modifies itself(randomly) doesn't make it evolutionary either
03:05:25 <aalm> s/modifies/modify/
03:05:45 <pZombie> aalm - no, just the modification alone does not. If however it survives longer than an unmodified one within a virtual environment you put it in, then there is a chance than it evolved
03:06:02 <klys> evolutionary theory has a few factors: the predator, randomicity, choice, and winners and losers.
03:06:45 <pZombie> so create multiple self modifying agents and put them in a complex virtual environment with a complex goal
03:07:23 <klys> the definition of self-modifying agents may prove too complex in the first place.
03:08:15 <pZombie> a goal that requires them to compete but in a way that collaboration and communication/forming groups against other groups/individuals is beneficial
03:09:15 <klys> those are your design goals. to talk about them with devs, you should probably set up a pseudocode algorithm.
03:09:40 <bcos_> For self modifying code the magnitude of the penalty depends on how soon you modify before you execute. If you have 2 things called A and B, you can "execute A, modify A, execute B, modifexecute A, mod, where you modify B, execute A, .." so that the gap between modify and execute is always large enough to avoid the penalty
03:09:46 <pZombie> i wonder if an AI agent could develop complex communication skills with other AI agents by defining a simple goal like "get the cheese before anyone else does" within a complex environment
03:10:17 <pZombie> if in order to get that cheese, it would raise its chances by first establishing some partnership and communicating
03:10:27 <bcos_> If it was truly intelligent it'd figure out that it doesn't need the cheese
03:11:01 <pZombie> in a evolutionary model, it is almost certain that it would happen at some point, given enough computing power to throw at it
03:11:04 <bcos_> ..and then probably create a nice painting instead
03:11:48 <klys> I don't think any of those things are probable. there are too few parameters to this pseudodeterminism I keep hearing about.
03:12:23 <pZombie> the problem is... there can only be one. Only one can have the cheese, yet getting it gives you a higher chance if you can convince other agents to cooperate temporarily
03:12:38 <pZombie> but when do you stab the cooperators in the back?
03:12:46 <klys> make friends not accomplices
03:14:30 <bcos_> pZombie: If all competitors are equally intelligent they'll all stab each other in the back at the same time, and none will be left to get the cheese
03:14:48 <aalm> .roa
03:14:48 <glenda> 89 Ask not what your profits can do for you, but what you can do for your profits.
03:16:55 * bcos_ tries to imagine a variation of the dining philosophers problem, where the forks are replaced by philosophers and the philosophers are replaced by forks.
03:19:02 <klys> transhumanism?
03:20:26 <bcos_> klys: We are the Borg, you will be assimilated!
03:20:49 <klys> then what comes out the other side?
03:21:12 <klys> if you assimilate me, you would have to release bcos_
03:22:54 <pZombie> True human level AI might not even be within the reach of limited human thinking.
03:23:21 <klys> the ideas of man are limited and changing.
03:23:54 <klys> .theo
03:23:54 <glenda> not everything is perfect.
03:24:22 <pZombie> there are fundamental limits. Known unknowables
03:24:59 <pZombie> like our inability to answer easily understood questions like "why does anything exist, rather than nothing?"
03:27:10 <klys> metaphysical realism posits that ideas exist in a separate place.
03:53:29 <jjuran> mmu_man: I'm curious, what are you working on with PEF?
03:55:17 <mmu_man> trying to get a version of the Haiku bootloader that would load on my BeBox
03:55:22 <mmu_man> ok, zz
03:58:15 <jjuran> neat
04:27:16 <radens> ugh qemu aliases all of gpio space as ram.
05:03:26 <geist> radens: hmm?
05:09:35 <klys> geist what's the simple kernel that has acpi?
05:09:45 <ybyourmom> Linux
06:03:23 <aalm> radens, what do you mean? (expect)
07:57:42 <geist> i'm a total trash mammal
07:57:59 <Mutabah> Hmmm?
08:07:14 <geist> oh was just thinking of #nitw again
08:07:16 <geist> what a great game
08:44:46 <zenix_2k2> guys sorry if i ask this in the wrong channel but is /dev/sda usually where it contains information about my partition table ?
08:47:32 <zenix_2k2> it's just i am trying to get the Disklabel type of my disk that i am using, or a flash drive without using parted, fdisk or lsblk
08:52:39 <Mutabah> zenix_2k2: The partition table is on the disk, yes :)
08:52:50 <Mutabah> (and /dev/sda is one of the raw disk files on linux)
08:53:44 <zenix_2k2> yea but it referred to the section where it stores the partition table right ?
08:55:23 <Mutabah> sorry?
08:56:02 <zenix_2k2> i mean there has to be a specific section on the Disk where it stores the partition table
08:56:06 <zenix_2k2> so /dev/sda refers to it ?
08:58:19 <Mutabah> There is a specific location on-disk for the partition table (the end of the first sector for MBR, and duplicate copies at ~1MB and -1MB for GPT)
08:58:38 <Mutabah> However, /dev/sda refers to the ENTIRE disk (it's a file that allows access to anywhere on the disk)
08:59:01 <renopt> /dev/sda refers to some disk, whichever is the first one found, linux doesn't make any guarantees in ordering
08:59:33 <renopt> if you plug in a flash drive and reboot, it's totally possible the flash drive would be /dev/sda
08:59:50 <renopt> maybe not likely, but possible
08:59:53 <zenix_2k2> wow, that's njew
09:00:54 <zenix_2k2> renopt: have you ever encountered the situtation like that ?
09:00:57 <Mutabah> renopt: Well, modern linux uses udev rules to try and keep things stable
09:02:47 <zenix_2k2> Mutabah: you know about the end of the first sector for MBR and... i am a bit confused, like how can i access the first "sector" and what does it mean by duplicate copies at ~1MB and -1MB
09:02:47 * Mutabah is away (not here ...)
09:02:58 <renopt> hmm, how does it do that, just keep track of it on-disk? still unreliable for installing :P
09:02:59 <zenix_2k2> oh com'on
09:04:44 <renopt> well you can open and read /dev/sda like a regular file, just need to write a thing to parse the first sector for MBR
09:05:19 <zenix_2k2> renopt: yea exactly i had the same idea but that "thing" sounds new to me, like how ?
09:05:21 <Mutabah> zenix_2k2: I suggest going and doing some reading, look up "MBR Partition table" and "GPT"
09:06:47 <renopt> zenix_2k2: like a simple C program, or whatever language you prefer
09:07:17 <zenix_2k2> yea i mean i do know C and Python but how can i parse the first sector
09:07:23 <zenix_2k2> Mutabah: ok then
09:12:11 <renopt> oh yeah, a sector is just block of 512 bytes
09:13:46 <renopt> just a*
09:15:26 <zenix_2k2> yea you know i used to try that when someone in #linux told me to look around the first 512 bytes inside /dev/sda
09:15:30 <zenix_2k2> but i found nothing actually
09:15:39 <zenix_2k2> i expected something like "gpt" or "dos" inside it
09:18:21 <renopt> heh that would be nice
09:20:57 <renopt> https://wiki.osdev.org/MBR_(x86)
09:21:00 <renopt> https://wiki.osdev.org/GPT
09:21:39 <renopt> ^ relevant reading material
11:37:10 <zenix_2k2> renopt: ok thk
02:47:21 <mrvn> I've had servers at work where whatever NIC had the network cable plugged in was eth1, the other eth0. Had to change our boot software because it assume we would always configure the servers to boot from eth0.
03:04:30 <glauxosdever> A forum member questioned the need for the osdev.org forums. Seems they're almost right
03:14:15 <glauxosdever> The "almost" part is that osdev is enabling "unrealistic goals"
03:18:29 <dormito> that... doesnt make an sense
03:19:08 <glauxosdever> The part where the forums are a ground for hostile posts is right.
03:19:32 <glauxosdever> That it's enabling "unrealistic goals", I disagree
03:20:00 <dormito> all human communication is a ground for hostile communication....
03:20:46 <glauxosdever> Right. Except roughly 50% of the posts on the forums are hostile/trolling/baiting/etc
03:20:57 <glauxosdever> That's too much
03:22:35 <dormito> really? I think we should preserve them so we can show them to our children and say "this is shit behavior, don't do it"
03:23:50 <glauxosdever> I don't know if you are being serious now. A forum where half of the posts are hostile don't make the forum look good and don't make the community look good
03:24:02 <glauxosdever> Of course, it happened
03:36:13 <dormito> Well my scheduler and runtime still need work if I want my SMP to actually be able to be schedulable
03:49:45 <klys> geist around
03:50:21 <klys> I was looking a zircon briefly
03:52:55 <klys> and came across: https://github.com/fuchsia-mirror/zircon/blob/master/kernel/platform/pc/acpi.cpp
03:54:12 <klys> sort of wondering how extensive acpi support is here
03:56:35 <bcos_> A while ago (a month or 2?) geist was talking about stripping out most of ACPI from the kernel, because it's a micro-kernel and most things that use ACPI are in user-space and not in the kernel
04:00:24 <dormito> it looks like it's primarly there for cpu enumeration (which afaik ACPI is the only way to do that on modern x86). of course I am not at all familiar with zircon
04:02:11 <bcos_> I'm not familiar either; but I think you're right (CPU and IO APIC enumeration and nothing else in kernel). I'd expect to find ACPICA ported to user-space running as some kind of service
04:02:27 <klys> looks like it has the HPET bits, too, which seem important.
04:02:55 <klys> am about ready to clone and start grepping around
04:08:40 <bcos_> klys: There's a "zircon/system/dev/bus/acpi" directory full of things - doesn't look like all of it though
04:08:49 <dormito> at a guess. they probably stopped doing AML processing in zircon
04:12:56 <klys> AcpiGetTable was in zircon/third_party/lib/acpica/source/include/acpica/acpixf.h
04:15:56 <bcos_> That looks like the whole of ACPICA
06:49:54 <geist> klys, bcos_ : yes. zircon has acpica in it
06:50:03 <geist> it's included in both the kernel (in a stripped down form) and in user space process
06:50:16 <geist> the kernel half of it i want to replace because there's only a handful of static tables to parse
06:50:26 <geist> i have a little library i've started putting together in another branch
06:52:46 <dormito> geist: so you don't do any AML processing in-kernel?
06:53:10 <bcos_> geist: Ah - I saw https://github.com/fuchsia-mirror/zircon/blob/master/kernel/platform/pc/acpi.cpp when klys was asking, and thought your changes were done :-)
06:53:57 <geist> that's correct
06:54:24 <geist> but that's the gist if it. thats about all of the place where the kernel interfaces with acpica
06:54:30 <geist> hence why it only needs a subset
06:54:40 <dormito> thats... suspicously sane. Having looked at actual AML code... I'm starting to wonder if BIOS devs know what they are doing :/
06:55:26 <geist> but.... before you bring up PCI it gets a lot more complicated
06:55:42 <geist> we just put that out in user space, and so the user space acpica process is a lot more complicated and has more responsibilities
07:42:28 <geist> think i might fiddle with my new acpi-lite library and get it production ready this weekend
07:49:45 <geist> i wanted to add it so i can read SRAT and SLIT as well and gather numa data
08:36:33 <dormito> hmm I havent see it written anywhere. but it seems x86 (at least the i386 ABI) only permits TLS segment to be in the GDT (and not the LDT)
08:38:21 <clever> geist: what about putting all acpi in userland, and having the kernel boot on a single cpu, and then rely on an (optional) userland daemon to parse the acpi and explain how to fire up more cpu's?
08:41:22 <isaacwoods> clever: less point and more complex I guess, static tables aren't very dangerous - an AML parser in kernel space can be?
08:43:58 <dormito> isaacwoods: the AML parses I've seen expect the kernel to just roll over and give them access to w/e the hell they want. so yeah I'd say they are dangerious :p
08:44:39 <dormito> incidently though. Apparently hostile file systems (intentionally malformed fs images) are a viable attack vector.
08:45:25 <clever> dormito: i was able to crash my MP3 player by having a 0 byte file as the first file on the external SD card, lol
08:45:45 <clever> pretty sure that device had no MMU or any reasonable OS
08:46:59 <dormito> well I was more refering to: apparently docker images, and other container systems may download filesystem images... and apparently that's been found to be an attack vector.
08:47:21 <clever> oh yeah
08:47:25 <clever> in that area, you have the pv-grub and pygrub
08:47:43 <clever> when you are booting a PV guest on xen, you need to parse the grub.cfg on the guest FS
08:47:49 <glauxosdever> I'm wondering how much you can do without ACPI
08:47:51 <clever> and pygrub is doing that, in the context of the host
08:48:09 <clever> so a malformed disk image can exploit pygrub and escape the VM
08:48:22 <clever> pv-grub is the solution to that, a fork of grub that works as a paravirtual xen guest
08:48:31 <dormito> clever: no I mean as kernel level exploit. as in they mount it as a loop devices, and then when the kernel goes to parse the fs..... code exectuion
08:48:36 <clever> so all parsing is already inside the guest, and you cant escape when you exploit
08:48:46 <glauxosdever> Power management needs ACPI, right? Things like poweroff, battery percentage detecting, etc
08:49:05 <clever> dormito: yeah, thats also a major issue, and likely why non-root namespaces cant mount things, which has been a problem with my work stuff
08:49:13 <glauxosdever> What else does need ACPI?
08:49:25 <dormito> glauxosdever: when you say "with ACPI" do you mean just AML, or any of the ACPI tables?
08:50:01 <glauxosdever> From what I've heard, not only in here, AML is the worse part. ACPI tables should be probably more ok
08:50:17 <glauxosdever> So, make "with ACPI" "with AML"
08:50:28 <clever> oh, related to the ACPI bytecode, there was a bug in mplayer, when dealing with chiptunes
08:50:38 <dormito> ok. then the AML tables still do a lot
08:51:04 <clever> the old nes "music" isnt so much of a music format, and more of just raw 6502 assembly, that runs in a VM, against a simulated SID chip
08:51:11 <dormito> typically laptops have an embedded controller (EC) that the tables controll. It will tell the kernel things like when the lids close, or open, or w/e
08:51:21 <clever> and the NES carts have multiple rom banks to deal with the limited address space
08:51:40 <clever> but the VM in mplayer doesnt enforce buffer limits correctly, so the 6502 assembly can freely address host ram, beyond the end of the buffer
08:52:05 <clever> and things like gnome try to auto-play music files you selected
08:52:11 <glauxosdever> So tables do things too. Why was AML invented then?
08:52:31 <bcos_> "without AML" = no power management (power on/off, fan speed, battery charge remaining), no hot-plug events, no IO APIC
08:52:32 <dormito> Also AML can privde thermal zone information. which, if you fail to have, you may damage your hardware
08:52:47 <glauxosdever> It's that bad then
08:52:55 <bcos_> Erm, no.
08:54:17 <bcos_> "things" (temperature sensor, etc) are connected to an embedded controller. If the OS doesn't support ACPI the controller sends SMI to firmware and firmware does basic power management using SMM. If OS does use ACPI/AML then controller sends SCI (an IRQ) to OS (which uses AML to handle the SCI and ..)
08:55:04 <dormito> bcos_: that's depending on the bios to get it right. which very often, it does not
08:55:34 <bcos_> It sort of needs to get it right for the time between power-on and OS enabling "ACPI mode"
08:55:48 <clever> i was able to crash something (either EC or AML) on my eeepc701 netbook, by toggling the charging status too fast (damaged power cord)
08:55:58 <clever> and then it just ceased to give status updates for if it was charging
08:56:03 <clever> until it was rebooted fully
08:56:43 <dormito> EC's can and do crash. a symtom of a crashed EC might be that the system wont reboot (unless you physically cut all power, and then turn it back on)
08:57:01 <clever> other EC features continued to work, like cpu fan speed control
08:57:21 <clever> so it might be one of the "threads" or a state machine deadlocking
08:57:24 <dormito> of course that depends on details of the EC, and details of the BIOS (if the bios depends on the EC to boot). but I have seen systems where that was happening
08:57:42 <clever> ive heard that the keyboard goes thru the EC on the eeepc701
08:57:55 <dormito> clever: that's pretty common.
08:58:09 <clever> there is also a way for the linux to read/write EC ram, but even reading the wrong area can break it, because the read forces bank switching
08:58:24 <dormito> iirc the ACPI specifications list some of the things ECs might do
08:59:03 <clever> the 701 also has a GPIO somewhere, that can toggle the power to an internal usb port labeled "webcam"
08:59:23 <clever> its just USB on a 4 pin JST connector, normally routed to a webcam in the top of the display
08:59:44 <clever> but if it fails to enumerate at bootup, the power is cut to the port
08:59:52 <clever> and there was a /sys entry on linux to turn it on/off freely
09:00:21 <clever> i had repurposed it for an FTDI and Xbee transmitter
09:07:50 <dormito> bcos_: also, you don't need AML to use the IO APIC (though routing info for SOME devices may be in there).
09:12:12 <clever> that reminds me, i was messing with cardbus/pcmcia and wifi on an old 486 machine
09:12:40 <clever> i was trying to get a wifi card to work on it, under linux, but the driver would just give an error at loading time, so i opened up the source
09:12:55 <clever> and i found that it wasnt able to figure out which IRQ was routed to that slot, so it just refused to run
09:13:21 <clever> attempts at patching it to run without an irq resulted in deadlocks, and trying to replace the irq with a timer, to abuse its shared irq support didnt help
09:13:32 <clever> and i wasnt able to brute-force the irq either, so i suspect the motherboard didnt route it
09:21:46 <glauxosdever> bcos_: I meant, "bad" as in "you can't do much without it"
09:24:14 <glauxosdever> AML is also bad because you need a parser (or ACPICA) running in the kernel, and the parser also needs to detect malicious AML code
09:24:56 <isaacwoods> and because AML is needlessly complex to make the firmware's job slightly easier
09:26:06 <clever> that reminds me, the one of the early xbox's had something similar, a custom bytecode responsible for bringing up dram, and the interpreter had to live in 512 bytes of rom
09:26:24 <clever> and to stop malicious bytecode from just disabling the DRM, it prevented all writes to $specialaddress
09:34:26 <klys> clever, for bringing up dram, or bringing up drm ?
09:34:36 <clever> klys: dram
09:34:58 <klys> so, a program to send refresh cycles?
09:35:21 <clever> klys: the xbox dynamically overclocks the ram to push it to its limit, but that code was too complex to fit in the 512 byte rom, and couldnt have its signature verified without having dram up
09:35:40 <clever> it has to set the refresh rate and clock freq, then test ram, and repeat, until its stable
09:36:13 <clever> oh, but the problem, is that the safety stopping you from writing to $specialaddress, does a full 32bit compare
09:36:23 <clever> but the IO bus is 16 bits wide, and silently drops the upper 16 bits
09:36:39 <clever> so setting any of those upper 16 bits bypasses the safety, and disables the boot rom in the northbridge
09:36:53 <clever> then it just runs unsigned code from the regular bios flash chip
09:46:08 <glauxosdever> Do you think UEFI is over-engineered? I think it is
09:48:41 <klys> I think UEFI amounts to having a copy of dos on your rig.
09:49:41 <glauxosdever> Given the UEFI spec is around 2600 pages long, I'd say an implementation would be a lot bigger than DOS
09:53:15 <bcos_> Do you think DOS is under-engineered?
09:53:15 <klys> more interesting might be if you have some idea of the size of UEFI firmware.
09:53:42 <klys> bcos_, it is. it just needs a little job control
09:54:01 <glauxosdever> BIOS is the opposite of UEFI. Probably worse than UEFI
09:54:48 <glauxosdever> BIOS is under-engineered, with extensions slapped over extensions slapped over badly designed interfaces.
09:54:57 <glauxosdever> It's plain ugly
09:58:21 <klys> glauxosdever, and does this give you a little incentive to learn UEFI ?
09:58:47 <glauxosdever> I will learn UEFI, sure, when I get back to osdev
10:01:12 <glauxosdever> But imagine how many bugs a UEFI (or BIOS) implementation may have. All of this initialisation code and these drivers
10:01:14 <geist> clever: that is an option (ACPI in user space)
10:01:38 <geist> the trouble is HPET and ioapic you probably want to know about before you really enable scheduling (and thus user space)
10:01:55 <glauxosdever> Of course, since we can boot from different devices, UEFI (or BIOS) will need to have drivers for these devices
10:02:05 <geist> but if you make all of that late binding, and for example just rely entirely on the PIC/PIT prior to learning about ioapic or hpet, then it's possible
10:02:26 <geist> but, like i now know, the number of tables you need to parse to understand the basics is pretty low
10:02:29 <glauxosdever> The only way I can think of it could be mitigated would be to put the OS in ROM (but that's going too backwards)
10:02:43 <geist> and it's only hundreds of lines of code to discover ACPI and parse MADT
10:03:30 <geist> once i finish it up i'll have a little acpi-lite library that should be fairly transplantable out of zircon
10:03:43 <klys> geist, would that code carry a few assumptions?
10:04:14 <geist> well, a few, like it's written in c++
10:04:39 <geist> https://fuchsia.googlesource.com/zircon/+/sandbox/travisg/acpi_lite/kernel/lib/acpi_lite/acpi_lite.cpp is most of the code right now
10:05:03 <geist> that plus https://fuchsia.googlesource.com/zircon/+/sandbox/travisg/acpi_lite/kernel/lib/acpi_lite/include/lib/acpi_lite.h is enough to find acpi and parse the MADT table
10:05:48 <klys> so, you just need a little more code, to find the HPET, assign IRQs, and discover CPUs ?
10:06:18 <geist> yah i need to write the HPET table parser and then that's prett much it
10:06:26 <klys> coo
10:06:39 <geist> the MADT table (also called APIC depending on how you describe t) has all of the cpu info and ioapic and interrupt redirection entries
10:06:46 <geist> which is enough to boot all the cpus in the system
10:08:39 <klys> there are three APICs, ioapic, local apic, and ?
10:08:46 <CompanionCube> glauxosdever: as complex as UEFI is
10:08:52 <CompanionCube> it's strictly better than the legacy BIOS
10:09:27 <geist> https://fuchsia.googlesource.com/zircon/+/sandbox/travisg/acpi_lite/kernel/platform/pc/acpi.cpp#101 is the place where it calls it, for example. it's a bit c++sy, because it uses a lambda to call back
10:09:36 <mrvn> UEFI also has some very stupid rules. Like you can only boot a FAT32 from harddisk but FAT16 from removable medium.
10:09:38 <geist> but can be easily reworked to be C callback friendly
10:10:03 <mrvn> Means the uefi partition on the disk needs to be ~200MB just to hold 5MB grub.
10:10:14 <CompanionCube> mrvn: does anything actually enforce that
10:10:23 <CompanionCube> my firmware sure as hell doesn't because if it did this box wouldn't boot
10:10:38 <mrvn> CompanionCube: UEFI fail to boot from FAT16 on disks. Don't even see it as bootable.
10:10:40 <geist> you can make a non compliant FAT32 partition that's 'too small'
10:10:47 <geist> which i've seen and it seems to be fine
10:10:56 <mrvn> geist: only by saing it's bigger than it is.
10:11:07 <geist> or using a tool that just bypasses those limits
10:11:10 <glauxosdever> Why does it even use FAT? Why isn't it filesystem-agnostic?
10:11:11 * CompanionCube looks at his 8M ESP
10:11:18 <geist> i have personally done that before, it's no big deal
10:11:23 <CompanionCube> glauxosdever: FAT is the lowest common denominator of filesystems
10:11:27 <geist> glauxosdever: alas no. MSFT had something to do with UEFI spec
10:11:32 <CompanionCube> also that
10:11:33 <geist> and thus FAT is part of the spec
10:11:46 <mrvn> glauxosdever: why does it have different lists of required filesystems for different devices?
10:12:11 <geist> that being said i think apple UEFI impementations are non standard in that they use HFS+ for their boot partition
10:12:12 <CompanionCube> '/dev/sda9 246145024 246161407 16384 8M EFI System' :)
10:12:28 <CompanionCube> geist: did apple even more to UEFI
10:12:36 <CompanionCube> or stick on efi
10:12:39 <mrvn> There also seem to be a hack to mark a partition as mobile and then UEFI can boot that even if the key is not registered in the UEFI.
10:12:44 <geist> CompanionCube: so question there is is that a FAT32 or FAT16?
10:12:49 <glauxosdever> What if an OS has a custom filesystem? Why should it use another partition for the bootloader?
10:13:03 <mrvn> NSA backdoor anyone?
10:13:11 <CompanionCube> glauxosdever: UEFI has the concept of filesystem drivers
10:13:14 <CompanionCube> it's just used ~never
10:13:23 <mrvn> glauxosdever: smart systems have a pointer to the filesystem driver in the boot record.
10:13:25 <geist> absolutely. you mark the UEFI Boot partition with a special bit in the GPT partition entry
10:13:34 <geist> and then uefi will scan it like any other ones on boot
10:13:49 <geist> there's a magic path within it that it'll pick up loaders from
10:13:53 <geist> EFI/BOOT/...
10:14:01 <klys> the concept of "booting from a sector" was deprecated in favor of "booting from a filesystem."
10:14:05 <CompanionCube> geist: the problem is linux doesn't really tell you that
10:14:11 <CompanionCube> it's all just 'vfat'
10:14:38 <klys> grub-efi cannot load a bootsector chainloader.
10:14:40 <mrvn> geist: the efi partition holding the filesystem driver still needs to be fat
10:14:45 <geist> mrvn: correct
10:14:56 <clever> grub also has an "install as removable" flag, that will use a special filename, allowing it to boot efi without being registered
10:15:08 <mrvn> geist: so all you're saying is that you can chainload your own loader that then knows your custom filesystem
10:15:15 <geist> correct
10:15:22 <geist> well, not 'all' but i'm saying you can do that
10:15:25 <aalm> that's how openbsd does it
10:15:28 <geist> or at least someone was saying it
10:15:35 <geist> that's what we're doing with zircon now
10:15:36 <mrvn> clever: debian installer can set that
10:15:50 <geist> we have our own EFI loader called gigaboot 20xx
10:17:00 <geist> the trick is if you put it down in a file called EFI/BOOT/BOOTx64.EFI then a amd64 machine will pick it up by default, even without it being registered in efi
10:17:06 <mrvn> Next year I probably have to figure out how to secure boot PXE.
10:17:15 <geist> and it seems to scan all devices it sees at boot and union them into the boot list
10:17:18 <CompanionCube> mrvn: https://gist.github.com/samis/fc9a881a1621162617ec4355d81dce23 this is what fsck says about the ESP
10:17:22 <CompanionCube> * geist
10:17:53 <mrvn> geist: so much for secure boot.
10:17:55 <geist> looks like fat12
10:18:03 <geist> mrvn: well, if you enable secure boot it doesn't do that
10:18:12 <geist> unless the thing is signed
10:18:25 <mrvn> geist: so you put a signed grub on it.
10:18:32 <geist> you can do that, yes
10:18:49 <geist> or the windows loader, being signed. tat's probably what a windows install media looks like
10:19:18 <geist> i dont precisely understand it but i think there's some support for iso9660 or udf in UEFI as well, and it can load via that
10:19:32 <CompanionCube> (and I can verify that it booted via EFI because I can poke at efivars)
10:19:39 <mrvn> Does UEFI support floppy images on CDs?
10:19:41 <geist> or, maybe it uses EL TORITO! and roots around inside the emulated floppy disk for EFI/BOOT/...
10:20:04 <geist> CompanionCube: yah i don thav eht espec in front of me, but i suspect UEFI is supposed to understand fat12/16/32
10:20:07 <mrvn> geist: it does for emularte HD afaik
10:20:26 <CompanionCube> geist: like I said, the firmware doesn't enforce the type restrictions apparently
10:20:38 * geist nods
10:20:39 <mrvn> CompanionCube: lucky you. Mine EFIs all do
10:21:08 <geist> anyway, i could look in the spec, but i'm not particularly interested in this minutae today
10:21:12 <CompanionCube> (if it did I'd just put the ESP on the HDD instead)
10:22:16 <mrvn> CompanionCube: The bad thing is that you can install on an external HD with ESATA and everything works fine. Then you take the HD with you to use somewhere else and that only has USB. Now it doesn't boot because wrong FAT.
10:22:25 <mrvn> and vice versa
10:23:59 <mrvn> geist: ever done something with hardware watchdogs on arm?
10:31:11 <CompanionCube> huh, fun thing: 'The rules defining the relationship between media size and FAT variants is defined in the specification for the EFI file system.' No such document exists.
10:34:05 <clever> other anoying things
10:34:34 <clever> my desktop refuses to boot legacy OS's until you entirely disable efi support, just having the CSM on doesnt do it (but only if an ESP partition is present)
10:35:07 <clever> my laptop allows you to whitelist binaries by hash for secureboot or register your own pubkeys, but the desktop only allows using the M$ keys
10:35:19 <CompanionCube> huh
10:35:19 <geist> mrvn: sure. but there's no one implementation
10:35:28 <CompanionCube> isn't it normally the other way around :p
10:35:32 <geist> most hardware watchdogs are some sort of count down timer that you just reset periodically
10:35:39 <clever> also, grub (and likely other bootloaders) technically have zero nvme support
10:35:48 <clever> they rely on the UEFI implementation to provide nvme drivers
10:36:02 <clever> and if your motherboard wasnt designed for that, then it cant boot from nvme in pcie adapters
10:36:15 <CompanionCube> hasn't GRUB's native drivers always been meh?
10:36:29 <bcos_> Erm. In theory PCI-e adapters can/should have UEFI driver in ROM
10:36:38 <geist> so usually you set the countdown (if you can) to something like a few seconds, and then pet it say every half a second
10:36:44 <klys> it seems there are these three: local apic, io apic, and msi. can the HPET be used via msi? does it supersede ioapic to the point of eclipsing control over hpet?
10:36:45 <clever> bcos_: its a dumb adapter, purely converting the connector, with zero chips
10:36:47 <geist> that way you have a nice safety factor in case of system load
10:37:06 <dormito> geist: people use the term 'pet'? I use 'kick' :[p
10:37:08 <dormito> *;p
10:37:10 <clever> because nvme is just pcie in a smaller form-factor
10:38:06 <geist> heh, pet is the nice one. because it's a watchdog
10:38:27 <dormito> yeah... but when I'm coding I'm not so nice I guess
10:38:42 <geist> well,that's one of the things about working for a big company, you gotta be nice
10:38:51 <geist> side note: i ordered a https://gigatron.io/
10:38:55 <geist> coming in the mail
10:38:55 <_mjg> dude
10:38:59 <geist> it's an interesting architecture
10:39:01 <mrvn> geist: I've got a Helios4 board (Marvell ARMADA 388, dual Cortex A9). I can set the global watchdog to reset the system and 2 minutes after boot it resets. But I can't find anything about how to reset the timer.
10:39:08 <dormito> clever: PCI ()and PCIe) has reservations for having rom chips on the device. maybe that's what bcos_ was refering to
10:39:23 <geist> mrvn: hmm, yah there's usually a pet register you hit
10:39:54 <mrvn> pet register?
10:39:57 <klys> geist, could you invoke msi with acpi_lite ?
10:40:05 <clever> dormito: yeah, but that would have to be built into the nvme drive itself, so it would depend more on the drive then the adapter
10:40:12 <geist> dont think MSI has anything to do with acpi that i know of
10:40:18 <geist> that's entirely a PCI level concept
10:40:27 <geist> except that of course yo need to know which irqs are used by the ioapic
10:40:42 <geist> or at least i think it'd be bad to MSI an ioapic vector
10:40:45 <klys> see, my previous question
10:41:33 <dormito> geist: I suspect that the FSB mode of HPET could be use to write to the MSI addresss (since those are on the chipset... normally). but how well that worked out would probably be very implementation specific
10:41:38 <geist> ah, no. MSI is a PCI level concept
10:41:48 <klys> thx geist
10:42:00 <geist> yah it might not work at all because it doesn't go 'through' the pci host bus/bridge/whatever
10:42:29 <geist> and if it did work it may end up being vendor/soc specific
10:43:55 <klys> then I'll ask this: will acpi_lite be enough to init the ioapic?
10:44:51 <geist> sure
10:44:57 <klys> very good
10:45:08 <geist> you just need to read some entries out of the MADT table for that
10:45:20 <geist> tells you where the ioapic(s) are and what the interrupt redirection entries are
10:45:30 <geist> which is almost always 9 -> 2 and nothing more in my experience
10:45:45 <dormito> geist: you mean 0 -> 2 ?
10:45:49 <geist> or something like that
10:45:57 <geist> i forget
10:46:25 <geist> do remember there can and arre frequently multiple io apics
10:46:36 <dormito> the timer, on hw that I've seen, gets moved from 0 (PIC) to 2. 9 usually has an entry... I think it's always the SCI (but no move).
10:46:40 <geist> but that's part of the description. it says where they are mmio wise, what their base global irq is and how many they have
10:47:10 <klys> so, you could just make a loop to find all the ioapics, and then spit out info on which ones are redirected to which other ones
10:47:22 <geist> yep
10:47:37 <geist> that's precisely what we do in that file in zircon. it loops through the table and builds another table of things
10:47:42 <geist> which is then used later when bringing up the ioapics
10:47:49 <geist> and when initializing the cpus
10:48:54 <klys> hmm I for some reason thought it was finding irq lines that had been reassigned by the pci bus
10:50:39 <bcos_> Probably need to call the AML "_PIC" method before actually using IO APIC though
10:54:37 <geist> hmm, i dont know
10:54:50 <geist> i think you do before something, but i think it's something farther downstream
10:55:30 <geist> anyway, all this aside, acpica is pretty embeddable. you can also just drag it in, implement the os specific glue and then forget about it
10:55:35 <geist> it's just fairly large
10:57:44 <geist> in the case of zircon it's a sizeable chunk of the size of the kernel and violates the concept of a ukernel so its gotta go
10:58:03 <dormito> just took a look at Method(_PIC) on my system. it largely seems to update the AML's own internals.... if you are not using AML (yet) it's probably unneded. (like for the PIC/PIT/HPET)
10:58:28 <geist> dormito: iirc i think that's right. i think you have to call it before you can call some other sets of AML methods
10:58:41 <geist> but i dont think it activates the ioapic per se, since you can still use ioapic prior to ACPI existing
10:59:00 <dormito> since IO APIC predates ACPI, I doubt using ACPI would become a prerequisit
10:59:05 <geist> right
10:59:15 <bcos_> dormito: For some (ancient) chipsets there was a IMCR to switch IRQ lines from PIC to IO APIC. Wouldn't assume all computers are happy to work without "_PIC"
10:59:39 <geist> well, perhaps. but who knows
10:59:41 <dormito> bcos_: and for those ancient computeres that IMCR is described in the MP tables
11:00:36 <bcos_> Yes - just saying there's nothing stopping a more modern variation now that all the hardware details are hidden/abstracted
11:01:36 <dormito> I think they'd have to get rid of IO APIC first. (which IMHO is fine.... it does too little now days)
11:02:02 <dormito> most of the problems it was designed to address have been resolved by things like MSI/MSI-X
11:02:58 <geist> thats fair except you still have non pci based things like hpet or whatnot
11:03:04 <geist> you'd have to invent a mechanism to MSI that
11:03:58 <dormito> geist: HPET has provisioning for 'FSB' interrupts... which look like the description for MSI... just make it work that way (and declare it part of the arch)
11:04:05 <geist> some very modern systems like the cavium thunderx2s are basically 99% MSI. it's kinda neat
11:04:30 <geist> even built in tings they just wrap a PCI config space around it and declare it non relocatable
11:04:36 <dormito> things like the EC would still be a problem.... but I'd say just give it a gpio on the chipset... and have the chipset (which already acts as PCIe devices) have an MSI vector for it
11:05:11 <geist> though i think they still have some fixed irqs for low level things like the uart and timers
11:05:32 <geist> but arm timers are very akin to local apic timers in that they are cpu specific and come in via a different mechanism
11:05:39 <dormito> yeah...
11:06:45 <dormito> I've seen a PowerPC chip (that has a dual-role PCIe controller) that it looks like most/all of it's interrupts are also via an MSI like mechanism
11:35:41 <dormito> I dont think I've seen sortie recently.
11:39:02 <dormito> sortix got added to a list of non-systemd OSes. I was gonna ask him if he know about that