#uACPI - a portable and easy-to-integrate ACPI implementation

1 messages · Page 11 of 1

north holly
#

Related to mde

#

*kde

#

Uhh

#

1,726,000,000,000 ops a second

fiery turtle
#

yeah uh

north holly
#

Sounds wrong

fiery turtle
#

what does your nanoseconds_since_boot return

north holly
fiery turtle
#

yeah idk sounds incorrect lol

north holly
#

Although it uses an internal function to convert from hpet ticks to nanoseconds

#

Maybe that's bugged

fiery turtle
#

sounds like it

north holly
#

Sorry for screenshotted code

fiery turtle
#

why do this

#

instead of just return ...

north holly
#

Because the hpet might not run on ns

#

Idk maybe it's stupid

fiery turtle
#

monotonic means >=

#

not that it has to increase every time

north holly
#

Silly me

fiery turtle
#

looks complex

north holly
#

It has the actual calculation done at the top of the function

#

Now I might've pulled that math outta my ass

hollow elm
#

are you sure the multiplication by 1000000000 doesn't overflow

north holly
#

Uh oh

#

I break uacpi

#

With my buggy value

fiery turtle
#

uacpi skill issue

north holly
#

Although I see no division there?

#

On that line

#

It's end_ts-begin_ts

fiery turtle
#

blind opcodes_per_second /= end_ts - begin_ts;

north holly
#

I'm blind nvm

#

I thought it was just equal

fiery turtle
#

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

north holly
#

Bruh

#

It gets 0

fiery turtle
#

lol

north holly
#

Maybe my math is a bit bugged lol

fiery turtle
#

i guess obos takes less than a nanosecond to run 1700 opcodes

north holly
#

Obos W

#

So fast it broke uacpi

median crest
#

can you add time travel to obos

fiery turtle
#

i should definitely add a guard against div by zero there

north holly
fiery turtle
#
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

north holly
#

Currently at two things added because of obos bug

#

That I remember

fiery turtle
#

lol

north holly
#

0 byte allocation protection

#

And this

fiery turtle
#

both are just good things to protect against anyway

north holly
#

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

fiery turtle
#

indeed

#

some people literally stopped working on their kernels because uacpi uncovered a ton of bugs

#

e.g. frosty

north holly
#

Poor frosty

left orbit
#

i have yet to test my kernel against uacpi

#

if i had an actual allocator i would

#

but i am too lazy sadmeme

fiery turtle
#

can still use it without an allocator for early_table_access meme

left orbit
#

i do that!!!

#

:^)

fiery turtle
#

oh damn lol

left orbit
#

a little wrapper around table_find

fiery turtle
#

nice

north holly
#

If only I had written damn comments

#

In my code

#

Like cool I got a calculation

fiery turtle
#

obofuscation

north holly
#

NOW WTF DOES IT DO

#

😭

fiery turtle
median crest
north holly
#

It looks like it overflows

#

And that's why

left orbit
#

i love UACPI_STATUS_UNIMPLEMENTED

fiery turtle
north holly
left orbit
#

thank you 🙏

fiery turtle
#

lol npnp

north holly
#

And it wasn't buggy on my third kernel

#

And it just worked™️

#

So obos obv better than astral

fiery turtle
#

not until we see ops per second

median crest
#

iretq osdev proejct real

north holly
north holly
fiery turtle
#

my bet is keyronex should outperform astral here

left orbit
#

with my first star being fadanoid i should really get back to work 👀

fiery turtle
#

we're about to see soon

jaunty fox
fiery turtle
#

are they slow in keyronex?

north holly
#

Surely acquiring a non acquired mutex isn't slow

fiery turtle
#

yeah mutexes are now used a few order of mangitude more often than before

north holly
#

Because it's not like uacpi is multithreaded during init

jaunty fox
#

the uacpi integration is using full mutexes because 1) they're highly debuggable 2) keyronex master branch doesn't have efficient pushlocks integrated

fiery turtle
#

so does astral i think

#

but there shouldnt be any contention so

north holly
#

wdym full mutexes

#

Like everything is a mutex...

jaunty fox
#

full mutexes are slow even if uncontended on keyronex because they are part of the generic waiting framework

fiery turtle
#

we're about to see just how slow meme

jaunty fox
#

it does a lot of work

fiery turtle
#

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

jaunty fox
#

but i am curious what the result will be

#

i think astral will win

fiery turtle
#

hmm well u do have a way to read the actual counter value on demand?

#

or does it read some cached counter

jaunty fox
fiery turtle
#

ah i see

#

yeah that res might be too slow, because with kvm it takes 4ms in astral

median crest
#

do a quick and dirty impl of the kvm timer halfmemeright

fiery turtle
#

true

north holly
#

According to obos, 33 timer ticks is 0 nanoseconds

#

At a frequency of 500 hz

#

Which is obviously wrong

#

I assume some math overflows

fiery turtle
#

astral is probably the only hobby os to use the kvm timer

north holly
#

obos will soon™️

median crest
fiery turtle
#

yeah and it looks very precise now

north holly
#

I'm just gonna assume obos' timekeeping is shit

#

Because it says 2945 ops/s

fiery turtle
#

lol

jaunty fox
#

i tried out the thread_safety branch on the new kernel and it appears to release a mutex that wasn't acquired

fiery turtle
#

a few orders of magnitude behind astral

fiery turtle
north holly
#

Maybe I should make a dirty implementation of kvm timer

jaunty fox
#

i did indeed, and it looks like it never does fail

fiery turtle
#

interesting, got a backtrace where that happens?

north holly
#

In case my timekeeping really is the problem (it isn't)

jaunty fox
# fiery turtle interesting, got a backtrace where that happens?
#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

fiery turtle
#

i wonder if c++ library implementation doesnt catch that if its a real bug

jaunty fox
#

it should if it is so i'm suspicious

zenith crescent
jaunty fox
#

just compacting the trace to fit discord

#

that's it up there

fiery turtle
#

yeah no its a bug

#

what does field->lock_rule say?

#

good thing i didnt merge it

jaunty fox
#

0

fiery turtle
#

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

jaunty fox
#

[uacpi]: successfully loaded 1 AML blob in 6ms (2356 ops total, avg 373183/s) success

fiery turtle
#

kinda annoying it wasnt caught on any platform

#

daamn faster than astral

jaunty fox
#

it's under KVM i should note

#

i'll send on the iso, 1s

fiery turtle
#

astral without kvm does 40k

jaunty fox
#

this new branch i can't test without kvm as it's wedded to TSC deadline at the moment

fiery turtle
#

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

fiery turtle
#

ill make a hash table in c++ and store acquired mutexes lmao

#

so that i catch stuff like this

jaunty fox
#

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

fiery turtle
fiery turtle
#

lmao

jaunty fox
#

wonder what the virus is

median crest
#

keyronex so fast big OS is censoring it

fiery turtle
jaunty fox
#

wtf

fiery turtle
#

lmaooo

jaunty fox
#

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?

fiery turtle
#

apparently it can do that? lol

jaunty fox
#

i have no rwx sections in either the kernel nor the virtio.kernext

#

maybe limine

fiery turtle
#

yeah

zenith crescent
#

limine is a PE because of UEFI

fiery turtle
#

ohhh right

jaunty fox
fiery turtle
#

that must be it

fiery turtle
#

ill try that thanks

hollow elm
#

not sure if it adds asserts for mutexes but it for example adds asserts in vector::operator[] etc

jaunty fox
#

limine has no RWX sections in any of its BOOT***.efi either

fiery turtle
#

ubsan literally couldnt care less about bogus mutex releases

#

The behavior is undefined if the mutex is not locked by the calling thread.

fiery turtle
#

i wonder what makes it go off then

hollow elm
#

do you ship storahci or something in the iso?

jaunty fox
hollow elm
#

hmm

jaunty fox
fiery turtle
#

if i have writable code sections im automatically a trojan?

jaunty fox
#

wait, is it without there? one sec

#

yeah, no virtio.kernext in there, maybe that helps

fiery turtle
fiery turtle
# jaunty fox here it is without virtio.kernext

im on wsl2 unfortunately, so same problem that made mathew add kvm clock support:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Warning: No invariant TSC, problems likely!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
hollow elm
jaunty fox
fiery turtle
#

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

jaunty fox
#

i had a quick skim, very reasonable

gentle peak
#

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

fiery turtle
#

anything strange about that file?

jaunty fox
#

it's just an elf solib

fiery turtle
#

interesting

jaunty fox
#
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

fiery turtle
#

looks fairly standard

#

must be some other entropy about it

left orbit
# jaunty fox

[uacpi]: successfully loaded 1 AML blob in 2ms (1705 ops total, avg 699779/s) brrrr

fiery turtle
#

damn

zenith crescent
fiery turtle
jaunty fox
jaunty fox
#

i fucked something up

fiery turtle
#

ah

left orbit
#

global_constructors_init: running

#

is there some c++?

jaunty fox
left orbit
#

ah, fair enough

fiery turtle
#

so 700k is the current record

#

i wonder how managarm fares here, will take a look later maybe

left orbit
#

i can consistently get 740k ops/s with that keyronex image

fiery turtle
#

damn

left orbit
#

but im wondering why there's only 1705 ops

fiery turtle
#

its 1705 in my qemu as well

jaunty fox
#

oh i see the fault cause now

fiery turtle
#

fadanoid must have a newer version

jaunty fox
#

uacpi_namespace_node_get_object got privatised

fiery turtle
left orbit
#

im on 9.1.1 so it's a pretty new version but i dont follow qemu closely so idk what's the latest

fiery turtle
#

see the new eval heleprs and object api instead

fiery turtle
#

could also be a command line difference

left orbit
#

i used the one fadanoid sent

fiery turtle
#

ah

left orbit
#

except for the +invtsc on cpu :^)

#

but i dont think that would change the aml

fiery turtle
#

fadanoid what's your current qemu version

jaunty fox
fiery turtle
#

interesting

left orbit
#

only one patch behind me

fiery turtle
left orbit
#

very interesting

jaunty fox
fiery turtle
jaunty fox
#

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)

jaunty fox
fiery turtle
#

UACPI_OBJECT_DEVICE_BIT in for_each_child

jaunty fox
#
 * allowed to reach, where 1 is direct children of 'parent', 2 is children of
 * first-level children etc.```
-1 for any?
fiery turtle
#

yeah, or UACPI_MAX_DEPTH_ANY

#

should add that to the comment, thanks for pointing out

jaunty fox
#

ascending_callback nullable as well which is worth noting probably

fiery turtle
#

true

jaunty fox
#

i wonder now how much faster it would be using pushlocks instead of the full mutex

fiery turtle
#

keyronex pushing the 1M ops per second ultrameme

frank canopy
#

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

left orbit
#

welcome to the uacpi gang

frank canopy
#

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)

left orbit
#

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

frank canopy
#

my current build issue is that i dont have a single libc header lol

left orbit
#

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?)

frank canopy
#

it seems the only thing uacpi pulls in from libc is in the platform/types.h

#

which can be overridden

left orbit
#

not too sure, haven't went down that road

#

but i don't think it's too much pain

#

to do it manually

frank canopy
#

ok got it to only complain about the uacpi_kernel_* things being not defined so thats a good start

fiery turtle
#

And welcome

fiery turtle
#
[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

hasty plinth
#

what about 8.1k ops/s?

fiery turtle
#

doable, just more code to write ig lol

hasty plinth
#

lol, I mean not that the precision of this really matters

fiery turtle
#

yea

dusky glade
#

@fiery turtle is there any big uacpi kernel api changes i should know about

north holly
#

Yes

dusky glade
#

i felt like u said there'd be one

#

oo[

north holly
#

It has been reworked

#

From the ground up

dusky glade
#

when is this getting pushed

north holly
#

Jk

dusky glade
north holly
#

There are like 3 changws

#

*changes

dusky glade
#

okay

north holly
#

All of which you probably don't have implemented anyway

dusky glade
#

okok

torpid root
#

2 functions iirc

#

mutex lock and ns since boot

fiery turtle
#

yup

north holly
#

Yeah

frank canopy
#

reading the comments on kernel_api.h, "event" is basically a semaphore yeah?

left orbit
#

iirc yeah

fiery turtle
#

yup

#

similar to eventfd on linux

frank canopy
#

ok cool

#

i saw event and was thinking like AutoResetEvent or ManualResetEvent at first

fiery turtle
#

i think this might be better tbh

torpid root
#

looks nice

frank canopy
#

id put avg before the number at the end still personally

#

but does look nice

fiery turtle
#

u would do (avg 10870/s)?

frank canopy
#

yeah

fiery turtle
#

hmm idk

frank canopy
#

idk why but it looks better to me shrug

fiery turtle
#

yeah im bad at these things so

fiery turtle
#

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

torpid root
#

there's always something to not like, but that one looks good

fiery turtle
#

i can always change it later i guess

#

uacpi log messages are not part of the stable api meme

fiery turtle
#

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

torpid root
#

based

fiery turtle
#

thanks!

frank canopy
#

\o/

#

eyy renamed the unimplemented get_ticks to the ns since boot name and my thing still compiles

fiery turtle
#

is your kernel available somewhere?

frank canopy
left orbit
#
b.verbose_llvm_ir = "agony.ir";
b.verbose_llvm_bc = "agony.bc";```
#

the zig experience

frank canopy
#

lol

fiery turtle
#

lol

fiery turtle
frank canopy
#

probably at some point

#

ive mostly been doing stuff in the zig server's osdev channel

fiery turtle
#

ah

left orbit
#

i like zig but i still think this server might be objectively better meme

frank canopy
#

this thread is like my first time doing stuff in this server lol

left orbit
#

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

frank canopy
#

ye

#

i hadnt worked on it in over a month until like yesterday lol

fiery turtle
#

oh interesting

#

u made actual bindings?

frank canopy
#

as i need em yeah

fiery turtle
#

could be cool to eventually make it a separate library like the rust bindings

left orbit
#

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

frank canopy
#

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

fiery turtle
#

lol

frank canopy
#

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

fiery turtle
#

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

frank canopy
#

just to initially get working

fiery turtle
#

memmove doesnt zero the src lol

#

it just handles the edge case where src and dst overlap is all

#

which memcpy doesnt handle

frank canopy
#

ahh

frank canopy
#
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

fiery turtle
#

think so

#

looks like u even have your own helpers for the RSDP and stuff

#

fyi uacpi has that functionality as well

frank canopy
#

which helpers?

#

cause all my old acpi code is in there for the various fixed tables

#

not removed yet

fiery turtle
#

For finding the tables

#

uacpi_table_find etc

frank canopy
#

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

left orbit
#

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

frank canopy
#

yeah that part is leftover code from before i decided to bring in uacpi

#

my plan is to use the installation handler callback actually

left orbit
#

man i love overthinking :^)

fiery turtle
#

Yeah no youre right

#

I was talking about xsdt walking code mostly

frank canopy
#

yeah thats now officially leftover legacy code since im pulling in uacpi now

#

predates that decision

fiery turtle
#

I see

frank canopy
#

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

fiery turtle
frank canopy
fiery turtle
#

I see, then it would work ofc, but still kinda hacky ig since that callback is meant to be more of a filtering mechanism

frank canopy
#

fair ig

#

though i dont think i keep pointers to any of the tables generally

#

im extracting info into my own variables

fiery turtle
#

Should be fine yeah

frank canopy
#

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 "^"

fiery turtle
#

Its a function that exists now lol

#

Grep again

frank canopy
#

oh neat

#

was reading before it got added then

fiery turtle
#

Yeah

#

Whats your use case for it?

frank canopy
#

the ascending/descending might cover it tbh

fiery turtle
#

Now im curious

frank canopy
#

my kernel device object keeps track of its parent so i build a true tree

fiery turtle
#

Ah

frank canopy
#

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

fiery turtle
#

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

frank canopy
#

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

fiery turtle
#

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

frank canopy
#

cool

fiery turtle
#

That is if I understood your question correctly

frank canopy
#

yep

fiery turtle
#

Cool cool

frank canopy
#

welp

#

i messed up but thats for a separate thread ig

hasty plinth
fiery turtle
fiery turtle
#

a ton of different address spaces require special handling

#

this is from ACPICA

#

ill have to implement all of that before 1.0 unfortunately

frank canopy
left orbit
#

limine time trl

vagrant hull
frank canopy
#

anyway made a thread in progress report where details can go lol

deft canopy
#

Well, it might be better to go to your thread

frank canopy
vast kestrel
frank canopy
#

only ones id think would be useful are memory, io, pci conf, and pci bar

kindred beacon
fiery turtle
#

And I think this is a thing on x86 as well on some hw

#

Or even on a lot of hw

vast kestrel
#

Well, I only ever looked at server hardware that has the most generic and plain acpi tables :^)

fiery turtle
#

Laptops have this serial and i2c crap

vast kestrel
#

Damn

#

Makes sense

#

Cause EC

fiery turtle
#

Strangely enough

fiery turtle
fiery turtle
gentle peak
#

is it supported by NT?

fiery turtle
#

Probably not otherwise Linux would support it too

gentle peak
#

then that's probably also the reason no hw uses it

fiery turtle
#

Some stuff they added to the acpi standard just didnt stick

frank canopy
frank canopy
#

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

fiery turtle
#

cool cool

#

now load dat namespace

frank canopy
#

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)

fiery turtle
#

nice

fiery turtle
#

uacpi is now at 140 stars, never expected to get this much
Thanks to everyone who starred!

median crest
#

hell yeah

vagrant hull
#

me not remembering if i starred it

#

let me check

#

oh yeah i already did, nice

fiery turtle
#

Based

frank canopy
#

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

frank canopy
#

for uacpi_kernel_install_interrupt_handler, do i need to apply redirects etc from the madt myself when using uacpi?

frank canopy
#

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)

fiery turtle
frank canopy
#

though i dont have proper code for either pic or io/apic yet so might as well go with ioapic/apic stuff for interrupts

hasty plinth
#

I don't imagine it's what you meant, but don't rebase both pics to 32 - put one at 40.

fiery turtle
#

yeah pic0 at 32, pic1 at 32 +however many pins (idr)

frank canopy
#

it is 8 per pic yeah

#

iirc

torpid root
#

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

frank canopy
jaunty fox
#

then it's uACPI's responsibility to call providing the appropriate tokens

frank canopy
#

the uacpi mutex methods dont pass around tokens iirc

#

only the spinlock ones

#

might be misremembering

torpid root
#

I don't think that would solve the problem

jaunty fox
torpid root
frank canopy
#

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

fiery turtle
torpid root
#

I do that

fiery turtle
#

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

torpid root
#

yes I'm doing that right now

fiery turtle
#

Or don't disable interrupts at least

#

Because that's certainly not intended

torpid root
#

yep until I have motivation to write a scheduler it does that

frank canopy
#

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

deft canopy
fiery turtle
frank canopy
fiery turtle
#

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

frank canopy
#

on qemu they would all be the same yeah

fiery turtle
#

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

frank canopy
#

yep

#

im not even really doing anything with the oemid either i was just printing it to my logs lol

fiery turtle
#

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?

frank canopy
#

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

fiery turtle
#
[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

frank canopy
#

neat

frank canopy
#

since "BOCHS " isnt showing up on real hardware anywhere most likely lol

fiery turtle
#

yeah

#

but also its a hardcoded string in qemu, so u can always kinda replace it and work around the check

frank canopy
#

true

gentle peak
frank canopy
#

oh id forgotten that leaf, had been checking leaf 0x8000000A eax bit 8

gentle peak
#

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

frank canopy
#

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?

gentle peak
#

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

frank canopy
#

cool that makes things easier lol

deft canopy
fiery turtle
#

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
fiery turtle
#

looks pretty nice in Astral i think

median crest
#

Epic

frank canopy
#

nice

fiery turtle
#

Thanks!

frank canopy
#

im getting some invalid opcode exceptions in the FACS header logging for some reason now

#

on an actual UD1 evidently

fiery turtle
#

unlucky

#

this works in astral soo idk

fiery turtle
#

is your memcmp implemented correctly?

frank canopy
#

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

fiery turtle
#

so does my userspace test runner tbh

#

add a printf there and see why its not entering the first if statement

frank canopy
#

the if signatures match one? that should be succeeding, its on the FACS and already fell through that memcmp

#

based on this objdump anyway

fiery turtle
#

what if u add a printf instead of conjecture 😛

frank canopy
#

on it

fiery turtle
#

well there's a return statement on line 46 soo like

#

idk how it's not reached in this case

frank canopy
#

added some printfs

fiery turtle
#

since FACS is not packed

frank canopy
#

in that case, what are your compiler flags on your working use?

fiery turtle
#

the default ones

#

well

frank canopy
#

this might be zig being more strict when it invokes the c compiler than default

fiery turtle
#

can u print the address of FACS?

#

like the pointer

frank canopy
#

on it

#

0x000000007FFE0000 is the phys address

fiery turtle
#

not that

#

the facs variable in that if statement

frank canopy
#

ohh

fiery turtle
#

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

frank canopy
#

ah yep 0xFFFFFFFF80A3FB2C

fiery turtle
#

i should use a memcpy there

#

1 sec lemme give u a patch to try

frank canopy
#

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

fiery turtle
#

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

frank canopy
#

giving it a try

#

yup that worked

fiery turtle
#

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

frank canopy
#

nw lol, always good to get bugs found

#

now to go find the off by one error in my own code lmao

fiery turtle
#

lol gl

#

pushed the fix

#

i wonder what flags its using to catch misaligned accesses

frank canopy
#

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

fiery turtle
#

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

frank canopy
# fiery turtle 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

fiery turtle
#

ah

frank canopy
#

-fsanitize=undefined -fsanitize-trap=undefined is what im finding in the clang invocation from zig

#

might actually be something with my target features tbh

fiery turtle
#

-fsanitize=address,undefined -g3 -Wall -Wextra -Werror

#

this is what my tests do

#

maybe i need trap as well idk

frank canopy
#

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

fiery turtle
#

hmm

left orbit
#

is there a list of all configuration macros i can use? i.e sized frees

fiery turtle
#

config.h

left orbit
#

ah thanks!

fiery turtle
#

np!

frank canopy
#

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

fiery turtle
#

definitely possible for at least some of them

#

a lot of them branch into the interpreter and from there its impossible to predict

frank canopy
#

yeah

#

but for the ones that would be possible it might be nice

fiery turtle
#

true

frank canopy
#

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

fiery turtle
#

yeah docs overall are kinda lacking right now so

#

something to improve in the future

fiery turtle
#

Unrelated, but my ACPICA fix got upstreamed into the Linux kernel as well, which is nice

hollow elm
#

what were the api changes for the new uacpi again?

#

i want to see if i can quickly update managarm to latest uacpi

fiery turtle
#

get_ticks -> nanoseconds_since_boot

#

and mutex acquires returning a status

#

just those two

hollow elm
#

also a change to the enumeration api i see

#

UACPI_RESOURCE_ITERATION_CONTINUE no longer exists?

fiery turtle
#

those got unified into one

#

its just UACPI_ITERATION_DECISION_CONTINUE

hollow elm
#

ah

fiery turtle
#

for all iteration callbacks

hollow elm
#

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

fiery turtle
#

yeah

fiery turtle
#

object is now opaque

hollow elm
hollow elm
#

to free the object arrays i just uacpi_free them right? i don't see a special dtor function in the header

fiery turtle
#

u dont free them

#

u just uacpi_object_unref the original object

hollow elm
#

ah it gives you a pointer to memory managed by the object

#

got it

fiery turtle
#

yup

hollow elm
#

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

fiery turtle
#

lol

#

curious how managarm is going to hold up

#

in terms of ops/s

hollow elm
#

i guess we'll see shortly

#

assuming i didn't mess anything up so far

fiery turtle
#

api breakage was mostly cosmetic so i doubt it

#

no ideological changes

hollow elm
#

what's the replacement for uacpi_namespace_node_get_object?

fiery turtle
#

what was it used for

#

to get the type?

hollow elm
#

yeah

fiery turtle
#

uacpi_namespace_node_type/uacpi_namespace_node_is

hollow elm
#

ah nice

fiery turtle
#

where did it get the said object from btw?

#

or rather, the node

hollow elm
#

uacpi_namespace_for_each_node_depth_first, that was gonna be my next question :^)

fiery turtle
#

yeah there's now a for_each_child

hollow elm
#

we're looking for a Device with a specific _ADR

fiery turtle
#

which supports filtering by type

#

so u can just use that with UACPI_OBJECT_DEVICE_BIT

hollow elm
#

ah nice

fiery turtle
#

didnt realize managarm used all that api tbh lol

hollow elm
#

this is in the pci code specifically

fiery turtle
#

makes sense

hollow elm
#

the package stuff was in the battery code

#

for _BIF and _BST

fiery turtle
#

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

hollow elm
#

okay now one last thing, uacpi_init_params is gone

#

how do i feed it the rsdp now

fiery turtle
#

uacpi_kernel_get_rsdp

hollow elm
#

ah

fiery turtle
#

that one is an old change

#

and just pass 0 to uacpi_initialize

hollow elm
#

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

fiery turtle
#

thanks for spotting

#

i like how its correct even in the comment

hollow elm
#

hm ```
uacpi-info: successfully loaded 1 AML blob, 589 ops in 0ms (avg 806251/s)

#

this is with KASAN enabled though

fiery turtle
#

huh

#

589 ops?

#

whats ur QEMU version

#

pretty much everyone whos posted here had ~1.7k

hollow elm
#

this should be 9.something, but without -M q35

fiery turtle
#

ah maybe thats why

#

can u try q35 + no asan?

hollow elm
#

sure

fiery turtle
#

800k with asan is kinda impressive

hollow elm
#
uacpi-info: successfully loaded 1 AML blob, 1747 ops in 1ms (avg 1569521/s)
fiery turtle
#

what the hell

#

phd code actually paid off

hollow elm
#

the power of building with -O2

fiery turtle
#

@jaunty fox you build keyronex with O2 as well right?

#

thats kinda insane damn

hollow elm
#

i like the new list of tables that's printed

fiery turtle
#

thanks!

#

sorta suggested by fadanoid as well

hollow elm
#

overall diff is pretty small ```
8 files changed, 71 insertions(+), 61 deletions(-)

fiery turtle
#

nice! i could take a look at the PR if u post it

fiery turtle
#

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?

hollow elm
#

sounds about right lol

fiery turtle
#

lmaoo

#

i wonder what would be ops/s if i did this in linux

#

probably not that much higher

fiery turtle
#

Very clean, LGTM

fiery turtle
#

If u want to use that

hollow elm
#

ci failed because the regex that was supposed to detect Depends on managarm/bootstrap_managarm#420 doesn't work

#

afaics

#

or i'm stupid

fiery turtle
#

I don't have access to the ci output I think

fiery turtle
#

Aka eval simple package

hollow elm
#

oh it fails because i'm stupid and it's bootstrap-managarm not bootstrap_managarm

fiery turtle
#

Lol

hollow elm
#

nice it automatically retriggered the checks after changing the pr message

fiery turtle
#

Nice

hollow elm
#

ah that's why ```yml
on:
push:
pull_request:
types: [opened, edited, synchronize, reopened]

fiery turtle
#

Makes sense

hollow elm
fiery turtle
#

We have more cases that could technically be simplified like that in managarm iirc

#

Like evaluation of ADR and stuff

hollow elm
#

true

#

_ADR could be simple_integer ig?

fiery turtle
#

Yup

#

Its just nicer to look at when there are no nullptrs anywhere I guess

#

Cleaner intent too

hollow elm
#

yeah

#

okay pushed that and it looks like ci is gonna pass

#

i think i'll go to sleep now

fiery turtle
#

Based

#

Looks cool

#

Gn qookie

hollow elm
#

gn

frank canopy
#

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

frank canopy
#

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

fiery turtle
mortal yoke
#

I also had to test uacpi on my kernel KEKW (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

torpid root
#

on kvm I get only 170k

#

also how do I get that table printout?

#

I just cloned the repo but it's not showing

torpid root
torpid root
#

not mapping memory as uncachable increased it to 250k

fiery turtle
torpid root
#

it should have

fiery turtle
#

also libc

torpid root
fiery turtle
#

or just tell me what git log shows as latest

fiery turtle
#

what does your uacpi log look like

torpid root
#

is this it?

#

FACS

fiery turtle
#

yes but it swallowed every other print lol

#

are u using a custom printf?

torpid root
#

hmm

#

fmtlib

fiery turtle
#

maybe something about the precision formatting in other printouts tripping it

torpid root
#

oh for printf I have eyalroz/printf

fiery turtle
#

add a printf into your log callback to print unformatted meme

#

to see if its ever called

torpid root
#

only FACS

#

nothing else

fiery turtle
#

can u add printf to dump_table_header?

#

maybe something in your code discarding those early logs?

torpid root
#

that's difficult with my build system

fiery turtle
#

are u using early table access?

torpid root
#

yes

fiery turtle
jaunty fox
fiery turtle
#

oh damn, u might get crazier numbers at O2 then

torpid root
#

I put everything in a vector and printed it later too

#

it just isn't called

fiery turtle
#

the rest are printed out in early table access init

#

in your case

torpid root
#

well nothing is printed when calling uacpi_setup_early_table_access

fiery turtle
#

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

jaunty fox
#

on my system:

[uacpi]: successfully loaded 1 AML blob, 2356 ops in 4ms (avg 478537/s)

#

with -O2

fiery turtle
torpid root
#

is this a uacpi bug?

fiery turtle
#

well

#

kinda

#

i should probably force the default log level in early table init

fiery turtle
#

This might yield numbers close to managarm on a fast system

jaunty fox
#

here is iso for anyone who would like to try (i can also try managarm if someone has an ISO)

fiery turtle
#

managarm gets built nightly i think

fiery turtle
jaunty fox
fiery turtle
#

yee

fiery turtle
jaunty fox
#

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

fiery turtle
#

thats probably true

jaunty fox
#

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

fiery turtle
#

makes sense

mortal yoke
fiery turtle
#

very close to 1M basically

torpid root
jaunty fox
fiery turtle
#

no invariant tsc

torpid root
#

-cpu max,+invtsc -M q35

fiery turtle
#

i have tried this here, didnt work

#

still no support for invtsc

torpid root
#

did you enable kvm?

fiery turtle
torpid root
#

no, it did without it

#

I need a faster allocator

fiery turtle
jaunty fox
#

it will go on with a warning about no invtsc if there's no invtsc, but if there's no TSC-deadline, it dies

torpid root
fiery turtle
#

wsl2 is not propagated invtsc i think

#

from the hyperv thing

jaunty fox
fiery turtle
#

fast memcpy + fast allocator is what makes uacpi fast i bet

jaunty fox
#

i will like to see how uacpi's performance changes if/when i add magazines or a similar layer

torpid root
#

well "my"

fiery turtle
torpid root
#

yes

fiery turtle
#

should be fast yeah

jaunty fox
#

cache colouring another fun idea

fiery turtle
#

then it's your allocator probably

#

are your mutex acquires fast if the mutex is not contended?

torpid root
#

it's a variation of the ticket lock from frigg

#

iirc

fiery turtle
#

should be fast then

#

well managarm is using those as well right

#

and it gets 1.5M so

torpid root
#

managarm uses the allocator from frigg right?

fiery turtle
#

think so

torpid root
#

I'll figure out how to use that when I have some free time

fiery turtle
#

well at least you're still on the same order of magnitude and not 150/s LULW

hollow elm
#

ill try keyronex on my machine to see how it compares to managarm on the same cpu

fiery turtle
#

nice

median crest
torpid root
fiery turtle
#

2x perf?

torpid root
#

yes

fiery turtle
#

not bad

torpid root
#

513k in release mode

dusky glade
#

💀

#

wanna know how much ops nyaux can perform per second

#

151

#

1838 ops in 12114ms

torpid root
dusky glade
#

(on tcg)

#

idk about real life hardware

#

never tested it on real hardware yet

torpid root
#

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

fiery turtle
#

what changes with ovmf?

torpid root
#

I don't know really

#

maybe memory layout

fiery turtle
#

strange

torpid root
#

oh I didn't change anything, ran it again and slowdown is only 50k now

#

I love when stuff like this happen

fiery turtle
#

lol

hollow elm
#

which is approximately the same as the managarm qemu args

fiery turtle
#

wtf is managarm doing that its so fast

jaunty fox
hollow elm
#

apparently yeah

jaunty fox
#

striking, i will investigate this

#

how annoyed would you be if i gave you more ISOs to try later?

hollow elm
#

not a problem

fiery turtle
#

managarm doesnt even optimize mappings to use HHDM i think

hollow elm
#

inb4 managarm just has broken time keeping

fiery turtle
#

lol

torpid root
#

lmao

fiery turtle
#

try adding a sleep(1) in uacpi

#

or a 1000 i guess

hollow elm
fiery turtle
#

yeye

#

can try adding a sleep in uacpi_namespace_load, right after it reads the starting counter

hollow elm
#

sure

fiery turtle
#

and if the numbers add up at the end, its probably correct

jaunty fox
#

by my tests, the cost of mutex acquisition seems to be minimal

#

that leaves the primary suspect the allocator

fiery turtle
#

yeah the frigg allocator doubled ilobilo's ops/s

#

could be that

hollow elm
#
uacpi-info: successfully loaded 1 AML blob, 1747 ops in 1002ms (avg 1743/s)
fiery turtle
#

looks fairly accurate then

hollow elm
#

feels like it's about a second too

fiery turtle
#

who said microkernels were slow meme

hollow elm
#

just need to have a phd :^)

fiery turtle
#

phd memcpy and allocator paying off

jaunty fox
#

merely removing the printf in uacpi_kernel_map helps me significantly

#

it also nicely panics immediately after namespace init