#uACPI - a portable and easy-to-integrate ACPI implementation
1 messages · Page 11 of 1
yeah uh
Sounds wrong
what does your nanoseconds_since_boot return
Hpet counter or smth similar
yeah idk sounds incorrect lol
Although it uses an internal function to convert from hpet ticks to nanoseconds
Maybe that's bugged
sounds like it
looks complex
It has the actual calculation done at the top of the function
Now I might've pulled that math outta my ass
are you sure the multiplication by 1000000000 doesn't overflow
Nope
Uh oh
I break uacpi
With my buggy value
uacpi skill issue
blind opcodes_per_second /= end_ts - begin_ts;
i would test managarm rn as well but it takes 10 years to rebuild, clone, run random commands and half of them break
maybe tomorrow
lol
Maybe my math is a bit bugged lol
i guess obos takes less than a nanosecond to run 1700 opcodes
can you add time travel to obos
i should definitely add a guard against div by zero there
Already have it
uacpi_u64 opcodes_per_second = g_uacpi_rt_ctx.opcodes_executed;
opcodes_per_second *= 1000ull * 1000ull * 1000ull;
if (uacpi_likely(end_ts > begin_ts))
opcodes_per_second /= end_ts - begin_ts;
ill add this obos protection
lol
both are just good things to protect against anyway
Actually three, the debug log mode was added to uacpi for people whose kernels suddenly become cursed by uacpi
And I was the first kernel to get cursed using uacpi
indeed
some people literally stopped working on their kernels because uacpi uncovered a ton of bugs
e.g. frosty
Poor frosty
i have yet to test my kernel against uacpi
if i had an actual allocator i would
but i am too lazy 
can still use it without an allocator for early_table_access 
oh damn lol
nice
obofuscation
cleanest glue implementation ive seen too
astral mogged uacpi by just working™️
i love UACPI_STATUS_UNIMPLEMENTED
true, only found a few minor bugs while implementing it
star'd
I still got the first kernel to use uacpi
thank you 🙏
lol npnp
And it wasn't buggy on my third kernel
And it just worked™️
So obos obv better than astral
not until we see ops per second
iretq osdev proejct real
Obosfuscation
It's only partially my fault it overflows
my bet is keyronex should outperform astral here
with my first star being fadanoid i should really get back to work 👀
we're about to see soon
it depends on whether you use mutexes
are they slow in keyronex?
100%
Surely acquiring a non acquired mutex isn't slow
yeah mutexes are now used a few order of mangitude more often than before
Because it's not like uacpi is multithreaded during init
the uacpi integration is using full mutexes because 1) they're highly debuggable 2) keyronex master branch doesn't have efficient pushlocks integrated
full mutexes are slow even if uncontended on keyronex because they are part of the generic waiting framework
we're about to see just how slow 
it does a lot of work
btw if u want u can try rebasing to the thread-safety branch yourself, if making a separate branch is problematic right now
ill merge it soon but im not changing anything probably
one more thing, there is no dynticks at all on old keyronex and timekeeping is ticks driven so it's going to be low res
but i am curious what the result will be
i think astral will win
hmm well u do have a way to read the actual counter value on demand?
or does it read some cached counter
only that, you could improve resolution by editing kernel/include/kdk/amd64.h line 16 (KERN_HZ from 64 to say 250)
do a quick and dirty impl of the kvm timer 
true
According to obos, 33 timer ticks is 0 nanoseconds
At a frequency of 500 hz
Which is obviously wrong
I assume some math overflows
astral is probably the only hobby os to use the kvm timer
obos will soon™️
all because I'm a stubborn little shit who wanted to keep using wsl2 despite hyperv not liking exposing the tsc to wsl
yeah and it looks very precise now
lol
i tried out the thread_safety branch on the new kernel and it appears to release a mutex that wasn't acquired
a few orders of magnitude behind astral
did you make sure to change the acquire_mutex api to return a uacpi_status?
Maybe I should make a dirty implementation of kvm timer
i did indeed, and it looks like it never does fail
interesting, got a backtrace where that happens?
In case my timekeeping really is the problem (it isn't)
#4 uacpi_release_aml_mutex (mutex=0xffff800000089fa0) at uacpi/source/mutex.c:248
#5 0xffffffff80027a85 in access_field_unit (field=field@entry=0xffff80000006d980, offset=<optimized out>,
offset@entry=0, op=op@entry=UACPI_REGION_OP_WRITE, in_out=in_out@entry=0xffffc80000043c10)
at uacpi/source/io.c:317
#6 0xffffffff800278ff in uacpi_write_field_unit (field=0xffff80000006d980, src=<optimized out>, size=<optimized out>)
at uacpi/source/io.c:460
#7 0xffffffff800256a1 in object_assign_with_implicit_cast (dst=0xffff800000073da0, src=src@entry=0xffff80010403c9a0)
at uacpi/source/interpreter.c:978
#8 0xffffffff800261e1 in store_to_reference (dst=0xffff800000073ce0, src=<optimized out>)
at uacpi/source/interpreter.c:2334
#9 0xffffffff80026296 in store_to_target (dst=0xffff800000073ce0, src=src@entry=0xffff80010403c9a0)
at uacpi/source/interpreter.c:4196
#10 0xffffffff80026e28 in handle_copy_object_or_store (ctx=<optimized out>)
at uacpi/source/interpreter.c:4229
#11 0xffffffff800269a1 in exec_op (ctx=ctx@entry=0xffffc80000053000)
at uacpi/source/interpreter.c:5405
#12 0xffffffff80026eed in uacpi_execute_control_method (scope=<optimized out>, method=method@entry=0xffff800000073c40,
args=args@entry=0x0, out_obj=out_obj@entry=0x0) at uacpi/source/interpreter.c:5757
#13 0xffffffff80032e35 in uacpi_eval (parent=parent@entry=0xffff80000006dec0,
path=path@entry=0xffffffff8003d4eb "_INI", args=args@entry=0x0, out_obj=out_obj@entry=0x0)
at uacpi/source/uacpi.c:669
#14 0xffffffff80032e7d in ini_eval (ctx=ctx@entry=0xffffc80000043f08, node=node@entry=0xffff80000006dec0)
at uacpi/source/uacpi.c:450
--Type <RET> for more, q to quit, c to continue without paging--
#15 0xffffffff800330b6 in do_sta_ini (opaque=opaque@entry=0xffffc80000043f08, node=node@entry=0xffff80000006dec0,
depth=depth@entry=3) at uacpi/source/uacpi.c:525
#16 0xffffffff80029377 in uacpi_namespace_do_for_each_child (...)
at uacpi/source/namespace.c868
wait sorry
i pasted somehing else
one sec
i wonder if c++ library implementation doesnt catch that if its a real bug
it should if it is so i'm suspicious
I'll return soon
0
yup
need to add that if at the bottom
--- a/source/io.c
+++ b/source/io.c
@@ -314,7 +314,8 @@ static uacpi_status access_field_unit(
);
out:
- uacpi_release_aml_mutex(g_uacpi_rt_ctx.global_lock_mutex);
+ if (field->lock_rule)
+ uacpi_release_aml_mutex(g_uacpi_rt_ctx.global_lock_mutex);
return ret;
}
try that real quick
how do i force the C++ standard library to abort if i release a mutex that wasnt acquired lol
[uacpi]: successfully loaded 1 AML blob in 6ms (2356 ops total, avg 373183/s) success
astral without kvm does 40k
this new branch i can't test without kvm as it's wedded to TSC deadline at the moment
ah
well still great results
managed to beat astral
i wonder if i should try to make it print in thousands instead
aka avg 373.1k/s
or just 373k/s
thanks for testing and finding the bug, very important
ill make a hash table in c++ and store acquired mutexes lmao
so that i catch stuff like this
no worries, pleased to be of assistance
an ISO if you want to see if it's the same result on your machine
needs qemu-system-x86_64 -cdrom keyronex.iso -serial stdio -M q35 -enable-kvm -cpu host and will die immediately after
bruh
lmao
wonder what the virus is
keyronex so fast big OS is censoring it
wtf
lmaooo
Two security experts point out to me that if code section is writeable, it is easily flagged by AV as malicious.
I check three of my programs, what they said are true, all with characteristic E0000000 (code section) - RWX.
surely it doesn't actually look in the ISO, find an elf (not a PE) with an RWX segment, and flag that?
apparently it can do that? lol
yeah
limine is a PE because of UEFI
ohhh right
this is what i was thinking, that might explain it
that must be it
maybe -D_GLIBCXX_ASSERTIONS?
ill try that thanks
not sure if it adds asserts for mutexes but it for example adds asserts in vector::operator[] etc
limine has no RWX sections in any of its BOOT***.efi either
ubsan literally couldnt care less about bogus mutex releases
The behavior is undefined if the mutex is not locked by the calling thread.
very strange
i wonder what makes it go off then
do you ship storahci or something in the iso?
no, not in this one
hmm
here it is without virtio.kernext
if i have writable code sections im automatically a trojan?
wait, is it without there? one sec
yeah, no virtio.kernext in there, maybe that helps
that one downloaded successfully
im on wsl2 unfortunately, so same problem that made mathew add kvm clock support:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Warning: No invariant TSC, problems likely!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
also looks like it doesn't add any for mutexes, since they just boil down to pthread calls
kvm clock is probably quite simple, i can look into that
yeah its pretty simple iirc
like a struct in memory that contains the values to convert tsc to elapsed time
and you either re-read it every time, or if it has a stable kvm clock bit or w/e u just read it once
i had a quick skim, very reasonable
I'd like to implement it as well, is there a spec for it or do you just have to figure it out from linux sources or something
btw is that like the virtio driver for your kernel or?
anything strange about that file?
yeah
it's just an elf solib
interesting
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 5 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000003770 0x0000000000003770 R E 0x1000
LOAD 0x0000000000003770 0x0000000000004770 0x0000000000004770
0x00000000000020b0 0x00000000000020b8 RW 0x1000
DYNAMIC 0x0000000000003780 0x0000000000004780 0x0000000000004780
0x00000000000001a0 0x00000000000001a0 RW 0x8
GNU_EH_FRAME 0x0000000000003220 0x0000000000003220 0x0000000000003220
0x00000000000000fc 0x00000000000000fc R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
not RWX segments
[uacpi]: successfully loaded 1 AML blob in 2ms (1705 ops total, avg 699779/s) brrrr
damn
might just be windows defender being a pain
-cpu host,+invtsc
same warning and it dies on PF lol
czapeczka setting the new standard
the death is expected
i fucked something up
ah
objc
ah, fair enough
so 700k is the current record
i wonder how managarm fares here, will take a look later maybe
i can consistently get 740k ops/s with that keyronex image
damn
but im wondering why there's only 1705 ops
its 1705 in my qemu as well
oh i see the fault cause now
fadanoid must have a newer version
uacpi_namespace_node_get_object got privatised
indeed
im on 9.1.1 so it's a pretty new version but i dont follow qemu closely so idk what's the latest
see the new eval heleprs and object api instead
8.1.1 here
could also be a command line difference
i used the one fadanoid sent
ah
fadanoid what's your current qemu version
9.1.0
interesting
only one patch behind me
btw, what were u using it for?
very interesting
oh, just to check if the object at some node was a device or not, now i do uacp_namespace_node_type()
is that during namespace iteration? If so, that now supports predefined object filters
and i did that when building the ACPI plane (the creation of device nodes according to the acpi layout, i discussed that some time ago)
it is, that would be even better
UACPI_OBJECT_DEVICE_BIT in for_each_child
* allowed to reach, where 1 is direct children of 'parent', 2 is children of
* first-level children etc.```
-1 for any?
yeah, or UACPI_MAX_DEPTH_ANY
should add that to the comment, thanks for pointing out
ascending_callback nullable as well which is worth noting probably
true
i wonder now how much faster it would be using pushlocks instead of the full mutex
keyronex pushing the 1M ops per second 
well im officially biting the bullet and adding acpi to my os (at least partially; i need sync primitives at some point too before fulling committing) and thank goodness for this library making that an even remotely viable thing to do lol
welcome to the uacpi gang
immediately running into the issue of not having stdbool trying to include it because im using zig lmao
but that should be solvable
(also out of curiosity, anyone got a sample of using uacpi with zig successfully? at least as far as build integration goes)
quite an old version of uacpi but it should still be the same-ish
as far as integration goes
ofc update the list of sources for starters
oh dang dont think i can steal from that in that it pulls in libc which i have no intention of doing lol
my current build issue is that i dont have a single libc header lol
i dont pull in the libc
just some freestanding headers
wait lemme check
ok yeah my bad
you can use uhhh
but those are gpl(3?)
it seems the only thing uacpi pulls in from libc is in the platform/types.h
which can be overridden
not too sure, haven't went down that road
but i don't think it's too much pain
to do it manually
ok got it to only complain about the uacpi_kernel_* things being not defined so thats a good start
[uACPI][INFO] successfully loaded 23 AML blobs in 1874ms (15804 ops total, 8K ops/s)
Do u guys like this output more than
[uACPI][INFO] successfully loaded 23 AML blobs in 1874ms (15804 ops total, avg 8194/s)
#polls message
vote ig
what about 8.1k ops/s?
doable, just more code to write ig lol
lol, I mean not that the precision of this really matters
yea
@fiery turtle is there any big uacpi kernel api changes i should know about
Yes
when is this getting pushed
Jk

okay
All of which you probably don't have implemented anyway
okok
yup
So basically nothing he has implemented
Yeah
reading the comments on kernel_api.h, "event" is basically a semaphore yeah?
iirc yeah
ok cool
i saw event and was thinking like AutoResetEvent or ManualResetEvent at first
ok hear me out
[uACPI][INFO] successfully loaded 23 AML blobs, 15804 ops in 1453ms (10870 avg/s)
i think this might be better tbh
looks nice
u would do (avg 10870/s)?
yeah
hmm idk
idk why but it looks better to me shrug
yeah im bad at these things so
[uACPI][INFO] successfully loaded 23 AML blobs, 15804 ops in 1163ms (avg 13580 ops/s) what do u think of this one
or maybe thats too verbose
yeah i dont like that it says ops twice
[uACPI][INFO] successfully loaded 23 AML blobs, 15804 ops in 1152ms (avg 13708/s) fuck it ig this one it is
there's always something to not like, but that one looks good
i can always change it later i guess
uacpi log messages are not part of the stable api 
stuff left to do for 1.0
some of those are skippable too tbh
like racey tests or BAREBONES_MODE
as far as thread safety is concerned most scary stuff is done too
finally
based
awesome!!!!
thanks!
\o/
eyy renamed the unimplemented get_ticks to the ns since boot name and my thing still compiles
is your kernel available somewhere?
https://github.com/Khitiara/imaginarium i havent pushed any uacpi things yet tho
b.verbose_llvm_ir = "agony.ir";
b.verbose_llvm_bc = "agony.bc";```
the zig experience
lol
lol
are u going to make a progress thread?
probably at some point
ive mostly been doing stuff in the zig server's osdev channel
ah
i like zig but i still think this server might be objectively better 
alright pushed my stuff, uacpi shim impl and also my uacpi zig externs in https://github.com/Khitiara/imaginarium/tree/main/src/krnl/hal/acpi/uacpi and the necessary c headers in https://github.com/Khitiara/imaginarium/tree/main/include if youre interested in how i integrated uacpi ig
this thread is like my first time doing stuff in this server lol
anyway you should definitely create a progress thread, it's nice to show off some cool stuff and maybe rant when things don't work
as i need em yeah
could be cool to eventually make it a separate library like the rust bindings
i was gonna do that at some point
but... C took over my kernel
rest in peace zigux
welcome yet unnamed project i randomly abandon for weeks at a time and suddenly figure out the bug that's been haunting me since day 0
mood
but yeah could be neat to extract zig bindings to a separate library
i do use existing types from my kernel for some of the uacpi types in my bindings though
lol
like i already had a struct for the sdt headers so i just use that directly
one nice thing about using bindings like this is the pointer types on the zig-side uacpi_kernel_xxx functions dont have to all be ?*anyopaque (which is what uacpi_handle translates to), i can just directly strong-type them
btw what is this about
pub export fn _memmove(dest: [*]u8, src: [*]u8, size: usize) callconv(.C) [*]u8 {
@memcpy(dest, src[0..size]);
@memset(src[0..size], 0);
return dest;
}
looks very very wrong lol
memmove doesnt zero the src lol
it just handles the edge case where src and dst overlap is all
which memcpy doesnt handle
ahh
pub export fn _memmove(dest: [*]u8, src: [*]u8, size: usize) callconv(.C) [*]u8 {
if(dest > src) {
std.mem.copyBackwards(u8, dest[0..size], src[0..size]);
} else {
std.mem.copyForwards(u8, dest[0..size], src[0..size]);
}
return dest;
}
then this is a valid impl given that contract
think so
looks like u even have your own helpers for the RSDP and stuff
fyi uacpi has that functionality as well
which helpers?
cause all my old acpi code is in there for the various fixed tables
not removed yet
wait you can use that to find the rsdp?
assumed it was for the others mostly
if so i might reimplement in terms of that
also not sure why im bothering with the uacpi_libc stuff tbh. only major difference over the naive impl would be vectorization and i have that turned off in my kernel so i dont have to save the vector registers on interrupts unless i do usermode context switching when i eventually add that
idk what infy is talking about but afaik uacpi requires you to pass in a physical rsdp address?
he may be referring to that you don't need your own acpi table parsing code
and you can use uacpi_table_find instead
yeah that part is leftover code from before i decided to bring in uacpi
my plan is to use the installation handler callback actually
btw sorry infy didn't mean for that to sound disrespectful
man i love overthinking :^)
yeah thats now officially leftover legacy code since im pulling in uacpi now
predates that decision
I see
had all my table parsing working perfectly but was getting annoyed by not being able to enumerate serial ports (on the isa bus) without parsing aml while being too intimidated by aml to try and write the parsing
and then someone mentioned uacpi lol
Idk what your plan for that is exactly, but note that the virtual mapping passed to that callback is only alive for the duration of the callback
i do a static mapping of all phys mem in the upper half so all basic phys->virtual mappings are permanent in my os
I see, then it would work ofc, but still kinda hacky ig since that callback is meant to be more of a filtering mechanism
fair ig
though i dont think i keep pointers to any of the tables generally
im extracting info into my own variables
Should be fine yeah
oh yeah other thing i was going to ask about is can we get a function to get a namespace_node's parent? afaict from reading headers the only public function for that is to go through the relative-path option passing "^"
the ascending/descending might cover it tbh
Now im curious
my kernel device object keeps track of its parent so i build a true tree
Ah
so i need to either do a bunch of depth-1 passes (which might fail given scopes i think) or track parents somehow
im not 100% sure how scopes and stuff work when trying to iterate devices since im just getting started rn
Scopes just allow to change the currently active scope, relative named objects created inside would reside inside that namespace instead of the current parents namespace
so if im iterating then theyll show up where the scope wants to put them then? dont need to worry about that then really ig
Yeah after the namespace is created the Scope() stuff is sort of abstracted away in that for you it will be as if it was natively created under that namespace
cool
That is if I understood your question correctly
yep
Cool cool
congrats on the merge, and just wanted to say I'm excited for 1.0 🎉
Thank you ❤️
What happened
a ton of different address spaces require special handling
this is from ACPICA
ill have to implement all of that before 1.0 unfortunately
officially now kernel too big for my bootloader lol
limine time 

anyway made a thread in progress report where details can go lol
"Too big" in what way?
Well, it might be better to go to your thread
yeah lol
Have you ever seen anything using these stuff?
only ones id think would be useful are memory, io, pci conf, and pci bar
I would assume that on some systems like embedded or laptops it might be useful to have devices downstream of an I2C/SPI/whatever controller be enumerable via ACPI
Well hobby osses ofc no, but Linux and stuff yes
And I think this is a thing on x86 as well on some hw
Or even on a lot of hw
Well, I only ever looked at server hardware that has the most generic and plain acpi tables :^)
Laptops have this serial and i2c crap
Pci bar isnt used by any existing hardware
Strangely enough
Yeah
Its not even supported by Linux
is it supported by NT?
Probably not otherwise Linux would support it too
then that's probably also the reason no hw uses it
Some stuff they added to the acpi standard just didnt stick
huh, interesting
happy to report that ive got as far as uacpi_initialize working now in my kernel \o/
and using find_table etc for the fixed table init stuff
thats up next!
just happy thata ive got uacpi initialized and caught back up to the same place i was at before pulling in the dependency
(and got to throw out a bunch of code that i didnt really like anyway)
nice
uacpi is now at 140 stars, never expected to get this much
Thanks to everyone who starred!
hell yeah
Based
kinda wild having it just work™️ when adding the namespace load and namespace init calls, thanks uacpi
there is some unimplemented errors because i return the unimplemented status from my pci read/write shims
but hey working is working and uacpi continues to work great
for uacpi_kernel_install_interrupt_handler, do i need to apply redirects etc from the madt myself when using uacpi?
Yes
cool
ill have to implement ioapic and irq redirect stuff then because id rather it not be overlapping with the exception vectors (even if 0x09 is deprecated)
well if using pic u can just rebase both to start at 32
nice
thats true ig
though i dont have proper code for either pic or io/apic yet so might as well go with ioapic/apic stuff for interrupts
I don't imagine it's what you meant, but don't rebase both pics to 32 - put one at 40.
yeah pic0 at 32, pic1 at 32 +however many pins (idr)
interrupts are being disabled when initialising uacpi. this seems to be related to my mutex disabling and re-enabling them
I just save the status on lock and restore on unlock
and even if I just sti without checking the previous value, interrupts are still disabled in the end
which leads me to believe that uacpi might be forgetting to release a lock
hmmmmm maybe not
// ints on
lock1->acquire()
// ints off, lock1 knows that they were enabled before
lock2->acquire()
// ints off, lock2 doesn't know they were enabled
lock1->release()
// ints on, enabled by lock1
lock2->release()
// ints off, disabled by lock2
@fiery turtle something like this might be happening
one solution is to never disable them in my release function, only enable
I'll see if it works
yeah that's a fix but I don't really like it
or per cpu global state
idk
do you use the same lock for both spinlock and mutex? i was under the impression that mutexes are generally higher level and dont leave interrupts disabled
let the lock acquisition function return a token and let the lock release function take one
then it's uACPI's responsibility to call providing the appropriate tokens
the uacpi mutex methods dont pass around tokens iirc
only the spinlock ones
might be misremembering
but what information would be stored in that token? interrupts status?
I don't think that would solve the problem
or IPL or similar
oh, the mutexes
I don't have a scheduler yet, so my mutexes are spinlocks
ah ok
uacpi might just be holding onto the mutexes tbh
depending on what its doing exactly
do you have SMP set up yet? if not just do what i do and make mutexes a no-op until youve got scheduler and smp up tbh
or what i did anyway, ive got scheduler set up now
I do
Store previous int state in your spinlock/mutex struct
I do that
Oh nvm
Why not implement like an actual mutex? They aren't supposed to disable interrupts because you might call into something that blocks while holding one
Your current implementation might sleep with interrupts disabled which will cause a deadlock
yes I'm doing that right now
yep until I have motivation to write a scheduler it does that
is there a way to get the rsdt's oem id from uacpi?
i think thats the only thing my acpi code returned that im not getting back out yet from my uacpi code
I don't think there'd be a way to get it directly from uACPI, but you can probably bring in uACPI's ACPI header and use that to help parsing the RSDP->RSDT/XSDT->OEMID
it doesnt actually store those tables, maybe it could tho
honestly even just a sort of callback or out pointer for the oem id would be nice, afaik thats basically the only thing of note in the rsdt/xsdt other than the rest of the tables that uacpi already stores
every other table has oem id as well
and iirc they're the same for all tables so u can use any other
not just the RSDT
well at least on qemu for sure
i did a dump of tables from my laptop the other day and got a couple of different ones iirc
on qemu they would all be the same yeah
on real hw it makes sense yeah
some tables come from the chipset, some come from hardware e.g. the gpu or device-specific power state information etc etc
yep
im not even really doing anything with the oemid either i was just printing it to my logs lol
btw
i was going to add that in to this pr i merged last week but
i have something like that in the works
[uACPI][INFO] RSDP 0x00007FFC133EBF60 36 v2 ( )
[uACPI][INFO] XSDT 0x0000604000001090 44 v1 (uTEST )
[uACPI][INFO] DSDT 0x000060D0000002B0 130 v1 (uTEST RUNRIDTB)
[uACPI][INFO] FACP 0x00006120000004C0 276 v6 ( )
would something like this work if uacpi dumped it instead of your kernel?
yeah absolutely
the only other reason id want it is to try and detect running in a hypervisor/qemu and that i can do by checking any of the oemids
[uACPI][INFO] RSDP 0x00007FFF237AACB0 36 v2 ( )
[uACPI][INFO] XSDT 0x0000611000000CC0 220 v2 (ALASKA )
[uACPI][INFO] DSDT 0x00007F8A9B571800 577646 v2 (ALASKA A M I )
[uACPI][INFO] FACP 0x00006120000004C0 276 v6 ( )
[uACPI][INFO] SSDT 0x0000619000000A80 916 v2 (PmRef Cpu0Cst )
[uACPI][INFO] SSDT 0x000061B000000080 1531 v2 (PmRef Cpu0Hwp )
[uACPI][INFO] SSDT 0x000061F000000080 3238 v2 (ALASKA PtidDevc)
[uACPI][INFO] SSDT 0x0000622000000100 5247 v2 (ALASKA I2Pm_Rvp)
[uACPI][INFO] SSDT 0x000062D000000400 39780 v2 (INTEL TcssSsdt)
[uACPI][INFO] SSDT 0x0000622000001900 4937 v2 (PmRef ApPsd )
[uACPI][INFO] SSDT 0x0000626000000100 10266 v2 (SocGpe SocGpe )
[uACPI][INFO] SSDT 0x0000619000000F80 908 v2 (PmaxDv Pmax_Dev)
[uACPI][INFO] SSDT 0x0000624000002100 7087 v2 (PmRef ApIst )
[uACPI][INFO] SSDT 0x0000621000000100 4444 v2 (ALASKA UsbCTabl)
[uACPI][INFO] SSDT 0x000062A000000200 21338 v2 (DptfTb DptfTabl)
[uACPI][INFO] SSDT 0x0000614000000040 427 v2 (PmRef Cpu0Psd )
[uACPI][INFO] SSDT 0x000062B000000200 24098 v2 (ALASKA TbtTypeC)
[uACPI][INFO] SSDT 0x000061C000000080 1838 v2 (PmRef Cpu0Ist )
[uACPI][INFO] SSDT 0x0000628000000100 14492 v2 (ALASKA Ther_Rvp)
[uACPI][INFO] SSDT 0x000062B000007200 27658 v2 (ALASKA MtlS_APA)
[uACPI][INFO] SSDT 0x0000621000001500 4027 v2 (PmRef ApCst )
[uACPI][INFO] SSDT 0x0000626000003100 10451 v2 (SocCmn SocCmn )
[uACPI][INFO] SSDT 0x0000625000034900 9342 v2 (INTEL IgfxSsdt)
[uACPI][INFO] SSDT 0x0000622000003100 5664 v2 (PmRef ApHwp )
[uACPI][INFO] SSDT 0x000062500003C100 9828 v2 (INTEL xh_mts2r)
[uACPI][INFO] SSDT 0x000061F000000E80 3331 v2 (INTEL PDatTabl)
Examples with some real hw dumps
neat
fair
since "BOCHS " isnt showing up on real hardware anywhere most likely lol
yeah
but also its a hardcoded string in qemu, so u can always kinda replace it and work around the check
true
for this you can use cpuid, bit 31 of either ecx or edx in leaf 1 is 0 on real hw and 1 in hypervisors
oh id forgotten that leaf, had been checking leaf 0x8000000A eax bit 8
just checked it's ecx
but yeah pretty much all hypervisors set that bit to 1
it's also how to check that the cpuid leaves at 0x40000000 exist
yeah that bit is working
whereas the 8000000A bit should also work for some hypervisors but isnt getting set
of curiosity, since i couldnt find any info on it with a quick search, is there any guidance for what interrupt priority level the SCI etc should be set at? ditto for remapping isa irqs, any general guidance?
ISA interrupt priorities are generally indicated by their IRQ numbers (higher number is lower priority) since that's how the PIC works
but I usually just mostly ignore interrupt priorities since it becomes a mess to manage very quickly
lowest possible
cool that makes things easier lol
little did you know, in 10 years when I eventually become dictator of IMD (Intel and AMD merged in the future, forming Intel Micro Devices) I'm gonna make them put BOCHS on the CPUs
wake up babe new uacpi changes are about to drop
- fixed bogus error handling in namespace_node_resolve
- uacpi now dumps all newly installed table headers, example:
[uACPI][INFO] RSDP 0x00007FFE882BFC80 00000024 v02 (uOEMID)
[uACPI][INFO] XSDT 0x0000604000001090 0000002C v02 (uTEST uTESTTBL)
[uACPI][INFO] DSDT 0x0000614000000040 00000199 v02 (uTEST TESTTABL)
[uACPI][INFO] FACP 0x00006120000004C0 00000114 v06 (uOEMID uTESTTBL)
[uACPI][INFO] FACS 0x0000606000000320 00000040
[uACPI][INFO] SSDT 0x0000000000000000 00000055 v01 (uTEST RUNRIDTB)
- a few misc thigns
looks pretty nice in Astral i think
Epic
nice
Thanks!
im getting some invalid opcode exceptions in the FACS header logging for some reason now
on an actual UD1 evidently
65 should be unreachable there
is your memcmp implemented correctly?
heres the jump
and im using your stdlib.c one
idk why that test is there, theres none at any of the other log lines
so does my userspace test runner tbh
add a printf there and see why its not entering the first if statement
the if signatures match one? that should be succeeding, its on the FACS and already fell through that memcmp
based on this objdump anyway
what if u add a printf instead of conjecture 😛
on it
well there's a return statement on line 46 soo like
idk how it's not reached in this case
i think its maybe checking the pointer alignment
since FACS is not packed
in that case, what are your compiler flags on your working use?
this might be zig being more strict when it invokes the c compiler than default
ohh
i think i know why
the header is created on line 613 as a stack variable
since it's PACKED it has an alignment on 1
ah yep 0xFFFFFFFF80A3FB2C
and zig defaults to strict compiler flags when compiling C code so the unaligned access causes the UD test to be generated instead that makes sense
good thing u use zig then
--- a/source/tables.c
+++ b/source/tables.c
@@ -37,11 +37,9 @@ static void dump_table_header(
struct acpi_sdt_hdr *sdt = hdr;
if (uacpi_signatures_match(hdr, ACPI_FACS_SIGNATURE)) {
- struct acpi_facs *facs = hdr;
-
uacpi_info(
"FACS 0x%016"UACPI_PRIX64" %08X\n", UACPI_FMT64(phys_addr),
- facs->length
+ sdt->length
);
return;
}
i think even this works lol
yeah the length is at the same offset in both structs but one is packed
should never have used this struct at all lol
thanks for finding the bug
or reporting it i guess
nw lol, always good to get bugs found
now to go find the off by one error in my own code lmao
turns out there was just a literal constant 1 labeled offset that i had due to misreading something so that was an easy off by one to find lol, though thats more for my own progress thread ig lol
i compile with both asan and ubsan
none of them cared in any of the test cases
and it runs like thousands of tests on all platforms for each commit
what was it for?
im automatically generating the bit mask type for object_type_bits since zig has bitpacked structs built in but i made a mental off by one error and thought the integer flag was bit 0 etc and programmed that in
ah
-fsanitize=undefined -fsanitize-trap=undefined is what im finding in the clang invocation from zig
might actually be something with my target features tbh
-fsanitize=address,undefined -g3 -Wall -Wextra -Werror
this is what my tests do
maybe i need trap as well idk
idk
C:\Users\robot\.zvm\master\zig.exe clang Z:\imaginarium\uACPI\source\opregion.c --no-default-config -fno-caret-diagnostics -mcmodel=kernel -fsanitize=undefined -fsanitize-trap=undefined -fno-sanitize=function -mred-zone -fno-omit-frame-pointer -fno-stack-protector -O2 -D_FORTIFY_SOURCE=2 -Werror=date-time -funwind-tables -fno-PIC -gdwarf-4 -gdwarf32 -MD -MV -MF Z:\imaginarium\.zig-cache\tmp\d44124af22e359ab-opregion.o.d -ffreestanding -I Z:\imaginarium\include -I Z:\imaginarium\uACPI\include -ffreestanding -nostdlib -DUACPI_OVERRIDE_LIBC -DUACPI_SIZED_FREES -DUACPI_OVERRIDE_TYPES -DUACPI_OVERRIDE_ARCH_HELPERS -DUACPI_DEFAULT_LOG_LEVEL=UACPI_LOG_INFO -c -o Z:\imaginarium\.zig-cache\tmp\d44124af22e359ab-opregion.o --serialize-diagnostics Z:\imaginarium\.zig-cache\tmp\d44124af22e359ab-opregion.o.diag heres the full invocation without the target feature stuff, maybe you can see something i dont
hmm
is there a list of all configuration macros i can use? i.e sized frees
config.h
ah thanks!
np!
one thing that might be nice to have would be docs on what errors each uacpi function can return (if thats even possible to determine)
would be useful in my zig bindings to try and make the error returns as narrowly typed as possible
definitely possible for at least some of them
a lot of them branch into the interpreter and from there its impossible to predict
true
not a huge deal since for the ones that are possible to predict i can usually go through and try to figure it out as i use the functions
yeah docs overall are kinda lacking right now so
something to improve in the future
Unrelated, but my ACPICA fix got upstreamed into the Linux kernel as well, which is nice
what were the api changes for the new uacpi again?
i want to see if i can quickly update managarm to latest uacpi
get_ticks -> nanoseconds_since_boot
and mutex acquires returning a status
just those two
also a change to the enumeration api i see
UACPI_RESOURCE_ITERATION_CONTINUE no longer exists?
ah
for all iteration callbacks
hm, uacpi_package is also no longer a thing
and uacpi_namespace_node_find
er no, the latter is just missing an arg
ah it has an out ptr now
yeah
uacpi_object_get_package
object is now opaque
can the out ptr just be null if i only want to check if it exists?
to free the object arrays i just uacpi_free them right? i don't see a special dtor function in the header
yup
ah wait, it's just an out ptr to a normal struct, not an out ptr to a ptr to a struct
i'm blind
what's the replacement for uacpi_namespace_node_get_object?
yeah
uacpi_namespace_node_type/uacpi_namespace_node_is
ah nice
uacpi_namespace_for_each_node_depth_first, that was gonna be my next question :^)
yeah there's now a for_each_child
we're looking for a Device with a specific _ADR
which supports filtering by type
so u can just use that with UACPI_OBJECT_DEVICE_BIT
ah nice
didnt realize managarm used all that api tbh lol
this is in the pci code specifically
makes sense
makes sense as wel
the current ops/s record is keyronex at about 850k/s peak i think
and it has slow mutex acquires too
uacpi_kernel_get_rsdp
ah
very minor typo: c // Returns the PHYSICAL address of the RSDP structure via *out_rsdp_address. uacpi_status uacpi_kernel_get_rsdp(uacpi_phys_addr *out_rdsp_address); the argument name contain be rsdp not rdsp
hm ```
uacpi-info: successfully loaded 1 AML blob, 589 ops in 0ms (avg 806251/s)
this is with KASAN enabled though
huh
589 ops?
whats ur QEMU version
pretty much everyone whos posted here had ~1.7k
this should be 9.something, but without -M q35
sure
800k with asan is kinda impressive
uacpi-info: successfully loaded 1 AML blob, 1747 ops in 1ms (avg 1569521/s)
the power of building with -O2
i like the new list of tables that's printed
overall diff is pretty small ```
8 files changed, 71 insertions(+), 61 deletions(-)
nice! i could take a look at the PR if u post it
managarm is the new official record holder at 1.5M ops/s
nyaux is the anti record holder at 150 ops/s
like 4 orders of magnitude behind?
sounds about right lol
lmaoo
i wonder what would be ops/s if i did this in linux
probably not that much higher
Very clean, LGTM
There's also uacpi_eval simple helpers, that dont take in an arg
If u want to use that
ci failed because the regex that was supposed to detect Depends on managarm/bootstrap_managarm#420 doesn't work
afaics
or i'm stupid
I don't have access to the ci output I think
This basically just saves an extra nullptr param
Aka eval simple package
oh it fails because i'm stupid and it's bootstrap-managarm not bootstrap_managarm
Lol
nice it automatically retriggered the checks after changing the pr message
Nice
ah that's why ```yml
on:
push:
pull_request:
types: [opened, edited, synchronize, reopened]
Makes sense
good to know, lemme change it to use that
We have more cases that could technically be simplified like that in managarm iirc
Like evaluation of ADR and stuff
Yup
Its just nicer to look at when there are no nullptrs anywhere I guess
Cleaner intent too
yeah
okay pushed that and it looks like ci is gonna pass
i think i'll go to sleep now
gn
now yall made me curious and
INFO (uacpi): successfully loaded 1 AML blob, 1705 ops in 0ms (avg 1705000000000/s)
with zig compiling uacpi using -Doptimize=ReleaseSafe
though i dont have a timer thing yet
so this is probably quite wrong
ok yeah that was just my lack of timer, here's the correct speed INFO (uacpi): successfully loaded 1 AML blob, 1723 ops in 7ms (avg 240107/s)
so fairly middling numbers
with ReleaseFast im up to 949526/s
not bad as well
I also had to test uacpi on my kernel
(ignore the page fault, its 99% because there is code that expects qacpi to be initialized)
this is on kvm btw, on tcg its like 48700/s in 35ms
on kvm I get only 170k
also how do I get that table printout?
I just cloned the repo but it's not showing
what affects speed the most?
not mapping memory as uncachable increased it to 250k
not bad
u sure u cloned the latest?
it should have
well check your tables.c, does it have a dump_table_header?
or just tell me what git log shows as latest
what does your uacpi log look like
maybe something about the precision formatting in other printouts tripping it
oh for printf I have eyalroz/printf
can u add printf to dump_table_header?
maybe something in your code discarding those early logs?
that's difficult with my build system
are u using early table access?
yes
could be this
most probably it was built with -Og
oh damn, u might get crazier numbers at O2 then
I don't think so
I put everything in a vector and printed it later too
it just isn't called
FACS is mapped and printed out only after uacpi_initialize
the rest are printed out in early table access init
in your case
well nothing is printed when calling uacpi_setup_early_table_access
i have a guess actually
try doing uacpi_context_set_log_level before setting up early table access
it's probably still zeroed at that point
so all logs are discarded
on my system:
[uacpi]: successfully loaded 1 AML blob, 2356 ops in 4ms (avg 478537/s)
with -O2
mhm makes sense now
i think iretq was getting 850k even with Og on his?
This might yield numbers close to managarm on a fast system
here is iso for anyone who would like to try (i can also try managarm if someone has an ISO)
managarm gets built nightly i think
this still needs invariant tsc right?
yeah, i need to integrate that kvm clock everyone talks of
yee
although the PR is still not merged, qookie needs to press the button
older keyronex i was trying hard to leave the way open for things like high-precision, dynamic tick on tricky clocks, but i now think this is not overly important as on modern power-efficient systems there should be an invariant tsc, while on older servers and such, neither dynamic tick nor high resolution times are desirable
thats probably true
so they will probably fall back to a fully tickful approach. which is fine and data from linux suggests that's what works best for server systems
makes sense
very close to 1M basically
also
that's to be expected
no invariant tsc
-cpu max,+invtsc -M q35
did you enable kvm?
does it print a warning about no invtsc support in keyronex log?
yes but im using wsl so that might have something to do with that
it will go on with a warning about no invtsc if there's no invtsc, but if there's no TSC-deadline, it dies
you can enable it in wsl2
this is probably the area where most of the gains can be made
fast memcpy + fast allocator is what makes uacpi fast i bet
i will like to see how uacpi's performance changes if/when i add magazines or a similar layer
I believe my memcpy is quite fast
well "my"
should definitely go up
is it rep movsb?
yes
should be fast yeah
cache colouring another fun idea
then it's your allocator probably
are your mutex acquires fast if the mutex is not contended?
should be fast then
well managarm is using those as well right
and it gets 1.5M so
managarm uses the allocator from frigg right?
think so
I'll figure out how to use that when I have some free time
well at least you're still on the same order of magnitude and not 150/s 
ill try keyronex on my machine to see how it compares to managarm on the same cpu
nice
Yeah whole reason I did go for kvm clock
I guess I'll use frigg allocator
2x perf?
yes
not bad
513k in release mode
at least ur not nyaux
💀
wanna know how much ops nyaux can perform per second
151
1838 ops in 12114ms
me neither
I don't have a terminal yet
I froggot
not using ovmf slows it down by almost 200k
I still have some optimising to do I guess
I'll switch from bitmap to buddy for my physical memory allocator
I should make a progress report thread instead of cluttering this one lol
hmm why does that even matter
what changes with ovmf?
strange
oh I didn't change anything, ran it again and slowdown is only 50k now
I love when stuff like this happen
lol
on my laptop [uacpi]: successfully loaded 1 AML blob, 1726 ops in 3ms (avg 551790/s) with ```
qemu-system-x86_64 -M q35 -enable-kvm -cpu host -smp 4 -m 2G -cdrom barebones.iso -serial stdio
which is approximately the same as the managarm qemu args
wtf is managarm doing that its so fast
while managarm gets about 3x that?
apparently yeah
striking, i will investigate this
how annoyed would you be if i gave you more ISOs to try later?
not a problem
managarm doesnt even optimize mappings to use HHDM i think
inb4 managarm just has broken time keeping
lol
lmao
well thor only has memory areas covered by the pmm mapped into the hhdm
yeye
can try adding a sleep in uacpi_namespace_load, right after it reads the starting counter
sure
and if the numbers add up at the end, its probably correct
by my tests, the cost of mutex acquisition seems to be minimal
that leaves the primary suspect the allocator
uacpi-info: successfully loaded 1 AML blob, 1747 ops in 1002ms (avg 1743/s)
looks fairly accurate then
feels like it's about a second too
who said microkernels were slow 
just need to have a phd :^)
phd memcpy and allocator paying off