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

1 messages ยท Page 7 of 1

fiery turtle
#

Didn't know qemu was in such a bad state on ia64

deft canopy
#

nothing really supports ia64 emulation

#

there's ski, but it's kinda iffy

#

simics used to support it partially, but was missing key parts

#

qemu-ia64 was part of a summer of code thingy

fiery turtle
#

Interesting

#

Why is that?

deft canopy
#

and then chickenes made a fork semi-recently to work on it more

deft canopy
fiery turtle
#

How come do they think that? (Im clueless about ia64)

deft canopy
#

not really sure, I think it's because it's VLIW

fiery turtle
#

Ah

deft canopy
#

the main issue is no one has really been motivated enough to implement one that's fully functional

fiery turtle
#

Interesting how its less supported than Amiga lol

#

I guess its way more complex

#

And its only for server hardware thats hard to come across

deft canopy
#

not quite, it was intended to support consumer use, it just wasn't popular enough
there are systems like the Zx2000 or Zx6000 which could've made great consumer systems, but due to how unpopular and expensive Itanium was they were only really used as workstations
there were also attempts at mobile Itanium chips which could've been great for things like laptops, or low-power systems but those didn't get super far

#

I believe @heady pewter mentioned that there was a cancelled project for a mobile Itanium implementation

fiery turtle
#

Oh cool

#

Didn't know about those

deft canopy
heady pewter
#

yes, there doesn't seem to be anything about it on the Internet

#

I'll have to see if I can track down the original architect and see if he is willing to comment

deft canopy
deft canopy
heady pewter
#

Itaniums were cheap from HP, because Intel had to supply them at cost ๐Ÿ˜›

fiery turtle
deft canopy
heady pewter
#

I forget for how long

#

it was part of the partnership

deft canopy
#

oh that, did it reduce the cost of Itanium chips?

heady pewter
#

for HP ๐Ÿ™‚

deft canopy
#

Ok that makes sense

sterile egret
#

There was a Google Summer of Code project years ago to add IA64 support to qemu, but the person really didn't get all that far. I actually didn't realize how primitive it was until AFTER I managed to apply 13 years of QEMU changes meme I ended up ignoring everything and building a new skeleton, dumping every bit of GSoC code...but that was on top of the original git repo, not qemu's, so I need to apply the changes/additions to qemu master...and I got distracted by other things before I did the latter meme

#

The GSoC thing had like a handful of instructions and the instruction decoder was hacked in from a BSD licensed debugger that I believe was already a dead project in 2011 lmao

#

ski is a good reference, but it's missing a fair bit.

rustic compass
#

@fiery turtle I got ownership of the uacpi-rs repository

fiery turtle
#

uacpi_state_reset vs uacpi_tear_down?

#

acpica does acpi_terminate which is horrible imo, its ambiguous whether it's related to power states

#

for reference, this is what it does:

fiery turtle
#

also can't believe i didnt have this check before

torpid root
north holly
left orbit
hollow elm
fiery turtle
fiery turtle
#

found a new collection of AML dumps

vast kestrel
#

This feels like pokemon

wind fiber
#

Gotta catch them all

vast kestrel
#

All the broken blobs

fiery turtle
#

I think this should work for non-recursive wipe of the entire namespace

void uacpi_namespace_deinitialize(void)
{
    uacpi_namespace_node *current, *next = UACPI_NULL;
    uacpi_u32 depth = 1;

    current = uacpi_namespace_root();

    while (depth) {
        next = next == UACPI_NULL ? current->child : next->next;

        /*
         * The previous value of 'next' was the last child of this subtree,
         * we can now remove the entire scope of 'current->child'
         */
        if (next == UACPI_NULL) {
            depth--;

            // Wipe the subtree
            while (current->child != UACPI_NULL)
                uacpi_node_uninstall(current->child);

            // Reset the pointers back as if this iteration never happened
            next = current;
            current = current->parent;

            continue;
        }

        /*
         * We have more nodes to process, proceed to the next one, either the
         * child of the 'next' node, if one exists, or its peer
         */
        if (next->child) {
            depth++;
            current = next;
            next = UACPI_NULL;
        }

        // This node has no children, move on to its peer
    }
}
fiery turtle
#

okay im back from my minecraft hiatus

#

first off now the initialization is atomic, meaning you can't end up with partially initialized uACPI due to some error

#

as a bonus i also added public api to reset api back to initial state

north holly
#

is there finally a lock

#

like is it thread-safe

fiery turtle
#

this much is still to do in terms of locks

#

only OSI and tables are threads safe right now

#

okay uhh some large tests are now failing due to memory leaks

#

this happens because i now reset uACPI after every run

#

this probably uncovered a preexisting bug where i would leak a reference or something

#

but never encountered it because nodes would always still be alive on program exit

fiery turtle
#

okay so as far as i can see its related to how deep object copy is handled, which is only used by NameOp...

#

but i cant come up with a repro atm, will have to dig deeper and actually look at the dsdts

#

only 700 cases of Name to look through in the reporducer blob...

#

okay uhh this fixes all leaks and all tests pass...

north holly
#

has the oberrow curse gotten to the reaches of the original thing that cursed obos (uacpi)

fiery turtle
#

nah its a bug thats always been there, just never showed itself because the global namespace was never freed before

#

basically a reference leak somewhere

#

anyway i need to figure out wtf is going on and for that i need a way to reproduce the leak

#

also i lied the bug didnt go anywhere, only the symptoms changed

#

aka the source of the leak changed

#

so it wasnt the deep copy thats at fault here

#

could it be the alias i wonder

#

Nope, the reporducer blob only has aliases to processors and the leaked object is a buffer

#
โฏ runner/build-linux-64bits/test-runner bin/large-tests/tablet_microsoft_surface_surface_laptop_3_4e426ab8062d/dsdt.dat --log-level warning
[uACPI][ERROR] unable to lookup named object 'EPCS' within (or above) scope '\_SB_.EPC_._STA': not found
[uACPI][ERROR] aborting method invocation due to previous error: AML referenced an undefined object
[uACPI][ERROR]     #0 in \_SB_.EPC_._STA()
[uACPI][ERROR] failed to disable fixed event 0

=================================================================
==11399==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 32 byte(s) in 1 object(s) allocated from:
#

okay found a blob with exactly one leak

#

this will hopefully help track it down

#

i have invented an absolutely genius object leak track down

#

technique

#

now i know exactly which node is responsible for the leak

#

because of the leak size

#

...aaand its a field connection

#

actual genius debug strat

#

and sure enough that was missing there

#

the only reason why i never saw this leak before was because no blob ever creates a temporary field unit with a connection

#

@north holly curse solved (also do u like my debug strat?)

north holly
#

yes

fiery turtle
#

thanks

#

also i kinda hate that this is unrefed recursively

#

but the connection must be a buffer object so

#

it cant recurse further

#

oh yeah its typechecked

#

so its not going to recurse

#

thats two more things off the checklist

rustic compass
#

whats the next todo you plan to do?

fiery turtle
#

the thing we talked about, aka the last box in the checklist

fiery turtle
#

Now that i can cleanly reset global state i can literally run the same test twice and they all pass!

#

not a single leak or variable i forgot to reinitialize

wind fiber
#

Nice work

fiery turtle
#

Thanks!

fiery turtle
#

wake up babe new uACPI kernel api just dropped

#

this time its optional and just convenience stuff

#

i dont like the name of this define

#

because its only part of what it does

#

but idk of a better idea

jaunty fox
fiery turtle
#

and wouldnt have to be exported anywhere

#

as uACPI would call it on its own

#

basically if your glue needs any initialization or state, this will allow for automatic initialization of that

#

aka just init hook

#

added some description on top

#

or maybe i should reword that to "glue code that needs global constructable state in order to work"

left orbit
fiery turtle
#

Not a thing on msvc

#

But yes more elegant

north holly
#

@fiery turtle is it possible for uacpi to use after free while being accessed in a multithreaded context?

#

I'm asking because I get a use after free in uACPI in types.c:1065 (uacpi_unwrap_internal_reference)

#

and the call stack goes down to uacpi_find_devices

#

while another CPU was running uacpi_get_pci_routing_table

#

yeah it's something to do with thread safety

#

Day one of waiting for uACPI thread safety

#

(I plan on saying that every day in this thread until uACPI is thread safe)

fiery turtle
#

It is possible yes

fiery turtle
#

Aka just wrapping uacpi up for a 1.0 release

#

Rn you can just wrap any uacpi invocation that might race under one mutex

north holly
#

ok

fiery turtle
north holly
#

Day two of waiting for uacpi thread safety

fiery turtle
#

Lmao

tired crater
#

he REALLY REALLY wants it

north holly
#

(when it finally is, I will start saying "Day n of uACPI thread safety) /j

north holly
#

day three of waiting for uACPI thread safety

fiery turtle
#

Rookie numbers, I've been waiting for a few months

vast kestrel
#

Add a global lock

#

And later you add an optimization release that magically improves the multi-threaf performance

fiery turtle
#

yeah for 1.0 i think ill do a GIL

#

but other subsystems will have granular locks

deft canopy
# vast kestrel Add a global lock

i think we should have UNfine locking everywhere
the OS should completely lock whenever a core enters supervisor mode
!!!!!!!!!!!!!!!!!!!!!!!!!!!

fiery turtle
#

a global kernel lock is relatively common for older kernels espeically when a lot of cores werent common

deft canopy
#

ya, but it's a bad idea on SMP systems, which tend to be the most common in modern desktop/server systems

fiery turtle
#

yeah

vast kestrel
#

Didn't freebsd have one til recently

#

Or still maybe

fiery turtle
#

maybe

jaunty fox
#

that's how they started to smp'ify

#

freebsd's one has had limited use for long time though

vast kestrel
#

I think the Linux one was removed in like Linux 2.6.30 or something

#

I remember freebsd still has their gil but not for everything

jaunty fox
fiery turtle
#

lmao

#

Giant

vast kestrel
#

Til the concept is called a giant lock lol

jaunty fox
#

kernel module loading/unloading, some keyboard drivers, a few random drivers, smb (the network fs?), some terminal stuff

fiery turtle
#

some stuff in acpi

#

but not too bad honestly

vast kestrel
#

Yeah

fiery turtle
#

god forbid my keyboard LED event races with module loading

#

this is known to kill people

vast kestrel
#

Exactly

jaunty fox
#

later the bsd funnel

fiery turtle
#

like the cake

jaunty fox
#

unix_master() is much cooler than mtx_lock(&Giant)

torpid ferry
#

iirc they got rid of Giant entirely a while back

#

now they just have like 3 massive locks

jaunty fox
#

openbsd is moving very slowly to wreck their giant locking (which they call the kernel lock or mp lock)

north holly
#

day four of waiting for uACPI thread safety

fiery turtle
#

Same

kindred beacon
#

Be the change you want to see ultrameme

fiery turtle
#

Lmao

deft canopy
north holly
#

Day 5 of waiting for uacpi thread safety

north holly
#

well seems like uACPI has caused lai to be completely unmaintained

fiery turtle
#

that last patch there is a fix for a bug i found in lai lol

deft canopy
hollow elm
fiery turtle
#

Thanks, will fix

north holly
#

day 6 of waiting for uacpi thread safety

jaunty fox
#

i should take a look at my storport shim again some day

dusky glade
#

hey does uacpi have rust bindings?

north holly
#

I think someone made some

#

but it's defintely far too early for you to port it

dusky glade
#

yea fair point

fiery turtle
#

although last commit there is may

rustic compass
#

developement is planned but currently halted

dusky glade
#

understandable

rustic compass
#

i will start once i need it for my kernel, which can be anywhere between next week and next year ๐Ÿ˜›

fiery turtle
#

lol

dusky glade
#

๐Ÿ˜ญ ๐Ÿ˜ญ

fiery turtle
#

maybe nyaux gets there before u

dusky glade
#

watch me

#

๐Ÿ˜Ž

fiery turtle
#

will do

deft canopy
rustic compass
#

its in a state in which i wouldnt recommend creating prs

#

but ideas are always welcome

fiery turtle
#

Noticed that ACPICA has an oversight where the kernel api initialization hook is only called once during early init, which is not enough because different stages of init need different APIs, e.g. work queues don't become available until later

#

so linux had to invent their own acpi_os_initialize1 to combat this oversight and then call into it manually

#

Thats why i decided to make the notion of uacpi_init_level public, as well as call the kernel init hook for each level when appropriate

#

basically this

#

and this is now public

hasty plinth
#

nice, sounds handy

fiery turtle
#

Thanks, I know im definitely going to use it in Astral

fiery turtle
hasty plinth
#

ah not necessary, but thank you anyway ๐Ÿ™

dusky glade
#

i dont care if its not mantained i need to use it like right now

mortal yoke
dusky glade
#

thank you

fiery turtle
#

i dont think its uhh

#

up to date

#

but with a bit of work it might be usable again

mortal yoke
#

and ig all of those sysdep functions might not be needed anymore, didn't you add a lot of default impls to uacpi?

fiery turtle
#

i did indeed

#

basically none of them are needed

dusky glade
#

@rustic compass is there documentation

#

for the crate

#

nvm i know how to set it up

#
fn install_interrupt_handler(&self, irq: u32, handler: Box<dyn Fn()>)
            -> Result<uacpi::Handle, uacpi::Status> {
        unimplemented!()
    }

box is not defined???

#

???

#

what is this trait

#

box isnt defined

fiery turtle
#

Resources:

OSDev.wiki

uACPI is a portable and easy-to-integrate implementation of the Advanced Configuration and Power Interface (ACPI).
Its main focuses are full NT compatibility, safety, and minimization of stack usage by avoiding recursion entirely.
Extra documentation can be found in the project's GitHub repo.

GitHub

UACPI bindings for Rust. Contribute to Shinribo/uacpi-rs development by creating an account on GitHub.

dusky glade
#

thanks

#

i still cannot get Box working

#

ugh

mortal yoke
#

Box is in alloc

dusky glade
#

box is not defined

#

i defined a global allocator

#

but i still cannot use box

mortal yoke
dusky glade
#

that gives me a error

#

no such thing as boxed

#

in core::alloc

mortal yoke
#

its not in core

#

its alloc::boxed::Box not core::alloc::boxed::Box

dusky glade
#

i still cannot use it

#

no such crate as alloc

#

could not find boxed in alloc

deft canopy
#

extern alloc

#

Make sure you're doing extern alloc first

#

@dusky glade

dusky glade
#

Yea it works now

deft canopy
#

there ya go

fiery turtle
#

okay soo.. back to work

#

im looking at how ACPICA implements early table access again

#

and as always its very awkward api

#

if u want early tables u have to do mental gymnastics that could've been done for you implicitly

north holly
#

oops I page faulted because uACPI wasn't thread safe and it took a long time to reboot
day n of waiting for uacpi thread safety

fiery turtle
#

Anyway here's my plan:

  1. make table mappings have refcount again, so introduce uacpi_table_{ref,unref}
  2. introduce uacpi_kernel_get_rsdp as it may now be requested from multiple places
  3. introduce uacpi_setup_early_table_access(initial_buffer, buffer_capacity, may_reallocate) where initial_buffer will be used by uacpi to store initial table descriptors
  4. make uacpi_initialize reallocate the descriptors from initial_buffer into a normal resizable heap array if early table access was requested, otherwise work as it did before
#

uacpi_initialize will also error out if any early tables are still mapped at this point

fiery turtle
#

which it already assumes heap availability in AcpiInitializeSubsystem anyway

jaunty fox
#

one thing i would find a bit dirty on the part of acpica

north holly
#

real chads just find the tables themself

jaunty fox
#

mapping tables being done with the same callback as mapping stuff that ought to be mapped differently

fiery turtle
#

thats an interesting thought, can u elaborate on that a bit?

jaunty fox
#

in my case a) i anticipate using the SLIT, SLAT, SLOT, whatever it's called that has NUMA locality information in it ahead of being able to map pages other than those found in the direct map b) if mmio is mapped i want to be able to map it with appropriate cache/shareability attributes, because aarch64 won't forgive me getting that wrong, and i don't want to map tables as if they're MMIO

#

i don't know if uacpi actually does need to map anything MMIO at any time

fiery turtle
#

lemme give u some context for these

jaunty fox
#

i'm just thinking of the delayed bootup i had when uacpi_kernel_map mapped cacheable

north holly
#

wait it's supposed to map uncached?

fiery turtle
#

a) Yes, this is the problem i want to solve iwth uacpi_setup_early_table_access
b) That's the thing, even uACPI doesnt know which cacheability attribute should be used for a mapping, as AML is allowed to map absolutely any physical address. What Linux does is scan the memory map and the decide the attributes based on that. On x86 it just does high half mapping for everything i think

#

So basically if u want b u have to solve it yourself

#

by finding the range AML wants to map in the memory map

#

e.g. if its normal ram u just map cached, if its reserved u map uncached, etc

jaunty fox
#

i can do that, will need to keep the memory map in persisted form but that's sensible anyway

fiery turtle
#

yeah i guess

#

For a) i need some elaboration from you as to what specific problem you want solved

jaunty fox
#

i can always set a flag to decide between "return hhdm offset" and "map it properly" if need be

#

and set that flag after i'm done with early tables and have set up the memory manager

fiery turtle
#

will this work for you @jaunty fox

// ------------ acpi.c
// acpi_early_init
static uint8_t buffer[4096];

// automatically calls uacpi_kernel_get_rsdp() and maps it
uacpi_setup_early_table_access(buffer, sizeof(buffer), false);

// ------------ pmm.c
// pmm_init
uacpi_table_find("SLIT", ...);
// do init
uacpi_table_unref(table);

// ------------ uacpi_glue.c
void *uacpi_kernel_map(addr, ...) {
    if (uacpi_get_init_level() == UACPI_INIT_LEVEL_EARLY)
        return addr + hhdm;

    return vmm_map(addr);
}

void uacpi_kernel_unmap(addr, ...) {
    if (uacpi_get_init_level() == UACPI_INIT_LEVEL_EARLY)
        // no-op, hhdm mapping
        return;
    vmm_unmap(addr);
}
fiery turtle
#

uacpi_get_init_level is already a thing

#

so i think it can be used for this very effectively

fiery turtle
fiery turtle
#

acpica has no notion of init levels, its either early or not

#

and thats a private global variable

#
if (!acpi_permanent_mmap)
    return __acpi_map_table((unsigned long)phys, size);
#

on x86 it just does early_remap

#

and then acpi_permanent_mmap is set to true during later init

#

right before the call to acpi_initialize_subsystem();

#

which on uacpi would bump the init level to UACPI_INIT_LEVEL_SUBSYSTEM_INITIALIZED

fiery turtle
#

found a very important bug in uacpi which was actually hiding another bug and thus making it not really a bug

#

thanks to this screenshot #1061407633745125397 message

#

what it says in the warning is, under the \_GPE namespace it already found a handler for event 8 called _L08 so it won't rebind it to _L08

#

but thats impossible since you cant have two nodes with the same name

#

under the same namespace

#

that would've been caught at init time earlier

#

Looking at the DSDT dump from that laptop, it indeed has two _L08 methods, but the second one is under a completely unrelated namespace

#

that should've never been reached

#

Anyway long story short

#

uacpi_namespace_for_each_node_depth_first had a bug where it would escape outside of the provided initial node and would iterate its peers

#

the fix was pretty simple

hollow elm
#

damn

fiery turtle
#

this also uncovered another bug, which is the _REG running code for some reason started iterating at the child node

#

this used to work simply because of this bug

#

Now im wondering

#

Would u expect uacpi_namespace_for_each_node_depth_first(node) to also visit node

#

or would u only expect it to visit the children of node

#

im tempted to just not make it visit the node

hollow elm
#

if i had to guess i'd say only children?

fiery turtle
#

thats what ACPICA does

#

so probably

#

its purely a matter of taste, initially i thought well for each means for each so the node is also one of the each

#

now im not so sure, i dont think it should

#

if u do for_each_node(_GPE) for example, u dont need _GPE visited, its the parent liek u dont really care

#

so ill probably change that, idk

fiery turtle
# hollow elm damn

this might be why the power button on your laptop didnt work, maybe we ended up calling some _REG thing multiple times because of this

#

or called something at the wrong time because of this

hollow elm
#

yeah i was wondering about it again

#

also out of curiosity had a look if there are any gpes and it seems like there were but the bios patches them out? there's \_GPE.XL{08,0E,19} and the bios patches out nodes by replacing the first underscore with an X for _S3 as well

fiery turtle
#

lol

#

usually they just hide them under ifs

#

but not everyone is so smart

hollow elm
#

for _S3 i saw the code that patches the dsdt to turn it into XS3 in a 100% legit ami source code leak

fiery turtle
#

is it available anywhere meme

#

like seriously they had to make the bios patch it instead of just doing

if (SUPP(3)) {
   Name (_S3, ...)
}
#

like im sure it just reads some io reg or whatever

fiery turtle
# fiery turtle

alright the people have spoken, i changed uacpi_namespace_for_each_node_depth_first to start its iteration at the first child and fixed the bug

#

@hollow elm hey uhh i know its a lot to ask but maybe if u have the time u could rebase managarm to latest uacpi and try running it on your hardware and see if anything changed or regressed (i currently dont have a working build of it), there's a chance that the power button works now

#

im waiting for the CI to finish and ill merge it

hollow elm
#

i can try in a moment yeah

north holly
hollow elm
#

i'll also see if my current xhci changes broke it or if it still works

fiery turtle
#

oh yeah

#

u havent tested your xhci changes on your hardware yet?

hollow elm
#

i'm doing some code cleanup now

#

like right now

fiery turtle
#

now it doesnt receive it at all

#

TLDR: no

fiery turtle
#

i should recheck on my hw as well

#

maybe my pc/laptop xhci works now

median crest
#

managarm xhci works now??

fiery turtle
#

well theres a chance

hollow elm
#

there is at least one more change i have stashed but it'll require some refactoring (ideally in the generic usb code so all the controllers don't need to reimplement the functionality)

median crest
#

if it does I will try managarm on my computers

hollow elm
#

i still haven't figured out why the usb hub doesn't work though

fiery turtle
#

hubs are the worst part

hollow elm
#

it theoretically should work but maybe i'm missing some step that qemu doesn't care about

#

it's like really close to working too, i start initializing the device behind the hub and the first control transfer fails with a usb transaction error

fiery turtle
#

its so close i can feel my hubs working already

hollow elm
#

:^)

fiery turtle
#

would it support hubs behind hubs as well?

hollow elm
#

it should yeah

fiery turtle
#

nice

hollow elm
#

theoretically hubs with xhci are easy enough, when you set up a new device there are some fields that point to the hub device and which hub port the device is connected to and that should be it

fiery turtle
#

theoretically caret

hollow elm
#

@fiery turtle do you have implementations for the new kernel functions that uacpi needs?

fiery turtle
#

i think its get_thread_id, which i just returned the pointer to current coroutine i think

hollow elm
#

also spinlock functions

fiery turtle
#

that one should be identical to mutex helpers, just return frg::construct<spinlock>(*kernelAlloc)

hollow elm
#

makes sense

fiery turtle
#

even simpler because acquire is not timed

#

i think i had the patch for that but mightve lost it

hollow elm
#

yeah i recall you sent some patch and i'm looking rn :^)

fiery turtle
#

i remember literally posting the implementation of get_thread_id

#

for managarm

#

i cant find it lmao

hollow elm
#

yeah same

fiery turtle
#

might've been return getCpuData()->activeFiber

#

or rather

#

return thisFiber()

hollow elm
#

sounds likely yeah

#

i'll just do that ig

fiery turtle
#

i think its correct

hollow elm
fiery turtle
#

there are 4 helpers

#
  • create
  • lock
  • unlock
  • free
#

this is create, free is the same but destruct

#

lock does return previous state

#

but i think the state is stored internally in managarm spinlock so u can just return 0

hollow elm
#

well depends on what type i use

fiery turtle
#

oh yeah

#

in my impl i just used the irq spinlock thats used everywhere else

hollow elm
#

actually, we don't have a combined spinlock + irq disabling

#

nvm it's litereally called IrqSpinlock

fiery turtle
#

wdym

#

yes lmao

#

thats the one

hollow elm
#

i remembered IrqMutex and looked at that

#

but that only handles recursively turning irqs on/off

fiery turtle
#

ohh

hollow elm
#

IrqSpinlock combines a spinlock and a global irqMutex

#

anyway

fiery turtle
#

yeah that makes sense

hollow elm
#

btw why is the naming not consistent?

#

{acquire,release}_mutex vs spinlock_{lock,unlock}

fiery turtle
#

acquire vs lock?

hollow elm
#

that and the order of subject and verb

fiery turtle
#

the latter is definitely wrong

#

acquire vs lock, idk
lock because it does so unconditionally, whereas acquire is more of a try to acquire based on the timeout

hollow elm
#

makes sense

fiery turtle
#

but i should fix that, thanks for spotting

#

break every implementation so far to keep the naming consistent meme

hollow elm
#

do it while you still have time to do so meme

fiery turtle
#

yeah i mean i have a warning in my readme

#

that things will break as this is pre 1.0

hollow elm
#

seems to still work in qemu

#

i'll write the image to a usb stick and try it

fiery turtle
#

nice

#

thanks for rebasing!

#

do u have just the one laptop?

hollow elm
#

i have some more

#

one ivb and 3 with some older cpus (around 2008 i think?)

#

one of the older ones has managarm installed on the hard drive and it actually works :^)

fiery turtle
#

does managarm boot there?

#

oh nice

hollow elm
#

on the ivb laptop i think it should boot

#

it was the first machine i got xhci working on :^)

mild patrol
#

Please inform me in this project you have here! Tail wags

fiery turtle
#

Sorry?

dusky glade
#

๐Ÿ˜ญ

hollow elm
#

oh i actually have one more laptop i forgot about

fiery turtle
#

lol

#

laptops appearing out of nowehre

hollow elm
#

i don't rememeber what cpu gen it is but it's a bit newer than the ivb laptop

dusky glade
#

can i have your laptop

#

actually im gonna buy all the laptops

dusky glade
#

anyways im procastinating on nyaux

hollow elm
#

while waiting for the image to write to the usb stick i can think about how i'm gonna refactor the usb code :^)

fiery turtle
#

does this image already contain usb refactors as well?

hollow elm
#

it has the code cleanup but it's gonna fail with a babble error i'm pretty sure

fiery turtle
#

ah

hollow elm
#

because we assume that for usb fs the ep0 max packet size is 8, but it's 64, so the device sends an overlong packet

fiery turtle
#

i see

hollow elm
#

i plan on getting that fixed along with the refactor

#

which is basically making more of the enumeration logic generic

#

and doing what linux does when addressing the device

fiery turtle
#

i hope u figure out the hub stuff eventually as well

hollow elm
#

so: read device descriptor, and only after that issue SET_ADDRESS

hollow elm
#

perhaps i just need to stare at the linux code harder

fiery turtle
#

indeed

hollow elm
#

@fiery turtle unfortunately no change in the power button not working

fiery turtle
#

oh well

#

no other regressions noticed there?

hollow elm
#

everything else seemed the same

fiery turtle
#

well thanks for testing anyway

#

maybe its the next bug i find meme

deft canopy
fiery turtle
#

tbh i dont think its a bug in uacpi, it probably isnt

#

either init order incorrect, or some driver managarm is missing that firmware expects to have been initialized

#

because everything initializes and works on that laptop, e.g. lid events arrive via EC just fine etc

#

but for whatever reason it probably assumes we're an old os and dont support ec power button events

fiery turtle
# fiery turtle
poll_question_text

Should uacpi_namespace_for_each_node_depth_first(node) also visit node

victor_answer_votes

6

total_votes

11

victor_answer_id

2

victor_answer_text

No, it should start iteration at first child of node

fiery turtle
#

i think logically yes makes more sense, but in reality u dont need it

hasty plinth
fiery turtle
#

yeah that makes sense

#

i really want to iron out the api and names before 1.0

jaunty fox
#

my feeling is the function should probably start visiting from the node itself

#

i would have a look at what acpica's analogous api does and imitate that

fiery turtle
#

and that visits only children

jaunty fox
#

odd, netbsd doesn't seem to call it

fiery turtle
#

AcpiWalkNamespace is probably the public one

#

the Ns one is internal i guess

dusky glade
#

uacpi integrated with linux when

jaunty fox
#

yes, that one is called

#

most notably here

fiery turtle
fiery turtle
jaunty fox
#

something i want to do in the future

#

as well as the devicekit tree proper, a second plane for a tree of acpi device nodes

#

this will help clean up the pci routing logic a little

fiery turtle
#

sounds interesting, maybe something to steal for my kernel if i ever get to it with all my plans meme

fiery turtle
#

interesting

jaunty fox
#

uacpi_kernel_create_mutex being called very early might be problematic

#

(i am looking for table access before i can allocate memory)

#

i don't have an immediate proposal on a good alternative though

fiery turtle
fiery turtle
jaunty fox
#

i can always hack around it myself if i must

fiery turtle
jaunty fox
fiery turtle
#

Are you actually implementing numa support for keyronex? Wow

fiery turtle
deft canopy
jaunty fox
#

come to think of it i'll need to be able to support allocating before numa setup if i want to support openfirmware

jaunty fox
# fiery turtle why is that

not a must-must i don't think but usually people find it less obnoxious to reconstitute the blob into a tree

fiery turtle
#

i wonder how linux handles it

#

anyways i am going to work on early table access rn, not sure when ill get it done, but soon hopefully

jaunty fox
fiery turtle
fiery turtle
#

being able to allocate them is only part of the problem

jaunty fox
jaunty fox
fiery turtle
#

huh really?

#

even get_thread_id would work?

jaunty fox
#

only the blocking case is a problem (i don't smp or multithread that early so that can only be erroneous)

#

but i can't say whether it would be the same on other kernels

fiery turtle
#

actually it wont use get_thread_id, thats only needed for recursive mutexes which are only for AML

#

so maybe u would be fine

#

ill implement early tables anyway i think, seems like a useful feature, and all kernels are different

fiery turtle
#

started working on this, will continue tomorrow

fiery turtle
#

Alright uhh.. back from the oss so hopefully back to work soon

#

Although I have tons of shit to do for work next week

north holly
fiery turtle
north holly
#

O

fiery turtle
#

Should've gone to plumbers tbh

hollow elm
#

should've gone to gnu cauldron :^)

fiery turtle
hollow elm
#

would've had a chance to meet arsen

fiery turtle
#

Would it be useful to add a pageable/nonpageable hint to uacpi_kernel_alloc?

#

most allocations should be pageable but not all of them

north holly
#

yes

leaden fox
#

yes

fiery turtle
leaden fox
#

If I stop procastinating I will be

fiery turtle
#

lol

leaden fox
#

but I can't imagine it not being useful

fiery turtle
#

do u have a progress report thing

hasty plinth
leaden fox
#

if you have no demand paging in your kernel just ignore the flag

fiery turtle
#

ill make it optional at compile time same as sized frees ofc

leaden fox
north holly
#

currently obos allocates all uacpi memory as pageable

#

which I think is around a megabyte?

#

idk

fiery turtle
#

this might be correct tbh, im not sure if uh

#

as long as all events and spinlocks are non pageable

#

should be fine i think

hasty plinth
north holly
#

well on qemu

hasty plinth
#

Granted it's a fairly new system, I imagine there's a lot going on

north holly
#

it's a megabyte

#

at least on my qemu config

fiery turtle
# leaden fox not yet :(

im currently working on UACPI_BAREBONES_MODE or such, this will only leave logging and map/unmap callbacks as host dependency and will allow to utilize table search api without aml execution etc

#

this might be useful for u

#

so u can start transitioning to full uacpi when able to but without having to roll your own skeleton table parsing

north holly
#

will uacpi have its own scheduler or smth

#

with that mode

fiery turtle
#

like i said only the table subsystem

north holly
#

oh

#

I thought it would implement the kernel api for you

fiery turtle
#

nah

leaden fox
north holly
#

and I was like "uKernel?!?!?1"

fiery turtle
#

it will straight up strip most of uacpi out

#

and leave only the table stuff

#

without mutexes and such

fiery turtle
north holly
#

still don't know why people can't just parse the tables themself

leaden fox
fiery turtle
#

pinned message

north holly
fiery turtle
north holly
#

I just don't look back at the boilerplate code I write

fiery turtle
#

especially since uacpi has a robust impl for that that handles firmware quirks and stuff

jaunty fox
#

the exact semantics of what can and can't be pageable will vary between kernels (keyronex mutexes, semaphores, etc can't be - but when keyronex has turnstiles, turnstile-backed rwlocks might be)

fiery turtle
#

@mortal yoke can u link those pls

mortal yoke
fiery turtle
fiery turtle
#

updated the pins with your link

jaunty fox
fiery turtle
#

thanks

jaunty fox
#

in general i have no objections to the uacpi api as it is today, pageable allocations could be a nice addition, and of course early table access

torpid ferry
#

how much memory is it used anyways on average?

deft canopy
fiery turtle
fiery turtle
#

i know most of it is never accessed again so its nice to be able to page it

fiery turtle
#

So close to having table refcounting work

#

the only thing left is now solving test runner mental gymnastics around whats a real physical address and whats a fake one

#

previously it was derivable from just the point at which kernel_map is called during init

#

now it may be called to map a table way later on

#

as long as its not referenced

#

rn the way it works is kinda dumb

void* uacpi_kernel_map(uacpi_phys_addr addr, uacpi_size size)
{
    if (!g_expect_virtual_addresses) {
        auto it = phys_to_virt.find(addr);
        if (it != phys_to_virt.end()) {
            auto mapping_it = it->second.find({ nullptr, size });

            if (mapping_it != it->second.end()) {
                virt_to_phys_and_refcount[mapping_it->virt].second++;
                return mapping_it->virt;
            }

            std::printf("WARN: remapping physical 0x%016" PRIX64
                        " with size %zu\n", addr, size);
        }

        void *virt = std::calloc(size, 1);
        mapping m = { virt, size };

        virt_to_phys_and_refcount[virt] = { addr, 1 };
        phys_to_virt[addr].insert(m);
        return virt;
    }

    return reinterpret_cast<void*>(addr);
}
#

ill just take the easy route and make the test runner bump refcount to the DSDT/SSDT itself so they're not unmapped

#

this should cut it

#

few new apis and some behavior change

#

(this is all work towards early table access)

fiery turtle
#

alright here it is

#

very close now

fiery turtle
#

early tables managed to break exactly 2 completely random tests

#

not bad

#

and ofc why would asan say anything

#

nvm its not a memory bug

#

DSDT revision was getting overwritten by late init code, since its now initialized earlier

fiery turtle
reef plover
#

This project is pretty nice, I'm gonna integrate it into my OS, especially for the device self-discovery.

#

My old code xd:

RSDT* rsdt = (RSDT*) memmgr_get_from_physical(rsdp->RsdtAddress);
    if(!doChecksum(&rsdt->h)) {
        printf("Warning: ACPI XSDT wrong checksum");

        return;
    }

    uintptr_t entries = (rsdt->h.Length - sizeof(rsdt->h)) / 4;
    for(uintptr_t i = 0; i < entries; i++) {
        ACPISDTHeader *h = (ACPISDTHeader *) memmgr_get_from_physical(rsdt->PointerToOtherSDT[i]);
        if (!strncmp(h->Signature, "MCFG", 4)) {
            MCFG* mcfg = (MCFG*) memmgr_get_from_physical(rsdt->PointerToOtherSDT[i]);

            if(!doChecksum(&mcfg->h)) {
                printf("Warning: ACPI MCFG wrong checksum");

                return;
            }

            uintptr_t mcfgEntries = (mcfg->h.Length - 44) / 16;
            for(uintptr_t j = 0; j < mcfgEntries; j++) {
                printf("PCIe base address: %x\n", mcfg->csba[j].base);

                pciBase = (uint8_t *) memmgr_get_from_physical(mcfg->csba[j].base);
            }
        }
    }
fiery turtle
#

thanks

fiery turtle
rustic compass
#

and why does: static uacpi_status initialize_from_rxsdt(uacpi_phys_addr rxsdt_addr, uacpi_size entry_size) take a size parameter? rxsdt_addr is the pointer to the rsdt so a size parameter shouldnt be needed?

fiery turtle
#

4 or 8 bytes

#

Xsdt or rsdt

fiery turtle
fiery turtle
rustic compass
fiery turtle
#

this is an internal function called by uacpi

rustic compass
#

woops

fiery turtle
#

will probably make checksum validation lazy

#

unless overridden by a flag

#

now it should be mapping one page at a time at max

#

at least at init time

#

also found a bug in that PR anyway

rustic compass
#

What is the intended path to recover from a OOM buffer error in the pre heap Phase?

fiery turtle
#

none really, because its a very very unlikely path

#

since user controls the buffer size, they can increase it

#

in the edge case that its needed

#

but i expect like a page to be enough

#

4096 byte buffer can currently store 73 table descriptors

#

i dont think ive even seen a machine with that many tables

rustic compass
#

I mean can i reset uacpi and try again with more memory?

fiery turtle
#

yeah ofc

#

it will auto-reset if init fails

#

but u can do uacpi_state_reset manually

rustic compass
#

๐Ÿ‘

fiery turtle
#

seems like 128 is enough as a hardcoded value for linux

#

if u give uacpi a page for early table heap u get 90 tables

#

also added this flag

#

previosuly this was the default behavior

fiery turtle
kindred beacon
#

have you tried setting up a handler for battery notifications?

fiery turtle
#

yeah

#

it worked

kindred beacon
#

did you also get a distinction between Notify(BAT0, 0x01) and Notify(BAT0, 0x80) et al

fiery turtle
#

wdym by that?

#

0x80 is status change iirc, so u should re-read it

#

0x01 idk to be honest

kindred beacon
#

yes, the problem is I ever only get 0x01

#

even when plugging/unplugging

fiery turtle
#

maybe linux has a define for it

#

does your blob do 0x80 at all?

kindred beacon
#

yep

fiery turtle
#

what is this

kindred beacon
#

qemu meme

fiery turtle
#

lol

#

i mean

#

its easy to see when qemu generates that

kindred beacon
#

how would Iย log that tho

fiery turtle
#

log what?

#

how would u install a notify handler?

kindred beacon
#

when qemu generated a notify

fiery turtle
#

like in qemu or managarm

kindred beacon
#

uacpi_install_notify_handler(node, handleBattery, nullptr);?

#

in mammogram

fiery turtle
#

yup

#

same way we do power button

kindred beacon
#

is the u64 value I get in the notification handler the 0x01/0x80/0x81?

fiery turtle
#

yup

kindred beacon
#

hmm

#

guess I'll try to debug mammogram on my test machine and try it there

#

might just be a qemu limitation

fiery turtle
#

which values do u get?

kindred beacon
#

only 0x01

fiery turtle
#

i mean

#

u have the patch code right

#

u can see when it generates it

kindred beacon
#

yes and I do not understand how notifications are generated lol

#

Iย tried looking at a DSDT dump too, no idea

fiery turtle
#

let me see

kindred beacon
#

this is what Iย get when plugging and unplugging

fiery turtle
#

its a bug in this guys code

kindred beacon
#

ah ok, good

fiery turtle
#

he sends 128 aka bit 7

#

so its GPE 7

#

which does Notify(1)

wind fiber
fiery turtle
kindred beacon
#

prolly does, same for windoze

fiery turtle
#

it updates the status if u boot into linux?

fiery turtle
#

looks like it does it unconditionally

kindred beacon
fiery turtle
#
    if (event == ACPI_BATTERY_NOTIFY_INFO)
        acpi_battery_refresh(battery);
#

it checks 0x80 only for this

kindred beacon
#

and how do I fix it meme

fiery turtle
#

looks like its correct

#

0x80 refreshes literally everything about the battery

#

0x01 would just re-read its state

kindred beacon
#

ok

fiery turtle
#

u can just look at that code i linked

#

acpi_battery_update unconditionally on notify

#

acpi_battery_refresh on 0x80

fiery turtle
kindred beacon
#

alright

fiery turtle
#

(in qemu)

kindred beacon
#

I tried, I can enumerate the battery but before I can get any more info it hangs on some unrelated shizz

fiery turtle
#

F

median crest
#

Cant wait to have a more proper fleshed out interface to give uacpi some more attention in astral

fiery turtle
#

that would be based

#

i need to rebase either managarm or astral to test the latest uacpi pr

#

and also wait until fadanoid does numa stuff

north holly
#

Not now though, as I need to get ready

#

Actually I could test it

#

Rn

#

Pretty quick

fiery turtle
#

sure

north holly
#

bruh uacpi_initialize api changes

fiery turtle
#

simplifications yes

#

just uacpi_initialize(0)

#

and ill probably make it take in a void

#

sooner rather than later

north holly
#

and how do I give it my rsdp?

#

@fiery turtle

fiery turtle
#

uacpi_kernel_get_rsdp

north holly
#

does it magically know the rsdp?

#

oh wait

#

that's kernel api

fiery turtle
#

lol

#

the nice thing aobut this api is retrieving the rsdp is arch specific anyway

#

so u can implement that part of the glue in arch specific place

median crest
#

limine<3 handles it for me

fiery turtle
#

u have arch_get_rsdp as well btw

#

now u dont even need that anymore

median crest
#

It just returns the limine provided ptr meme

fiery turtle
#

yeah

#

but if u were to implement e.g. itanium it would be different

north holly
#

@fiery turtle obos boots with the new limine revision on qemu

fiery turtle
#

okay nice that tells me at least i didnt fuck it up too much

#

i basically rewrote all of table init

north holly
#

I'm testing real hw

fiery turtle
#

u can try uacpi_setup_early_table_access as well if u want

north holly
#

I need to go soon

fiery turtle
#

aight thanks for testing

north holly
#

np

fiery turtle
#

limine revision?

north holly
#

version

#

commit

#

whatever

fiery turtle
#

limine?

north holly
#

uacpi

fiery turtle
#

lmao

north holly
#

sametyhing for me

fiery turtle
#

limine and uacpi are the same thing, yes

median crest
#

ubootloadwe

fiery turtle
#

anyways thanks for testing

north holly
#

Or the one real hw I've

fiery turtle
#

nice

north holly
#

Atm

fiery turtle
#

the init for kernels that don't use the hh for mapping tables (like astral) should be faster now too

north holly
#

hh?

fiery turtle
#

hhdm

north holly
#

Yeah I realized that

torpid root
#

uacpi stable api when?

fiery turtle
#

after 1.0

#

soon hopefully

torpid root
#

noice

fiery turtle
#

aight time to merge early table support, i tested it in astral and oberrow tested in in his kernel

#

then ill proceed to the thing ive been procrastinating on

#

which is thread safety

#

@vagrant hull sorry for ping but is there any way i can detect whether __popcountdi2 is natively available at build time?

vast kestrel
#

Isn't there a builtin popcount?

fiery turtle
#

yeah i use it atm

#

but the problem is it generates undefined references to that thing for the default amd64 target

vast kestrel
#

I mean, you can maybe make a weak impl for it or something

fiery turtle
#

i can but msvc doesnt support that

#

or well, this is gcc specific anyway

vast kestrel
#

It also doesn't support builtin_popcount lel

fiery turtle
#
uacpi_u8 uacpi_popcount(uacpi_u64 value)
{
#ifdef _MSC_VER

#ifdef _WIN64
    return __popcnt64(value);
#else
    return __popcnt(value) + __popcnt(value >> 32);
#endif

#else
    return __builtin_popcountll(value);
#endif
}
#

yeah i do this atm

vast kestrel
#

Looks good enough tbh

#

If you need a compiler rt then link against it

#

Same for all the 64bit math things for 32bit

fiery turtle
#

yeah like i can do that fine, its just extra annoyance for the users of uacpi ig

vast kestrel
#

It's the exact same for 64 math tho, unless you don't use it ig

fiery turtle
fiery turtle
vast kestrel
#

64/64 is not available, it needs a function

#

For the x86 target at least

fiery turtle
#

oh yeah

vast kestrel
#

Like I feel like the correct thing is to link against the compiler rt if it's needed Shrug

#

GCC/clang assumes they exist

fiery turtle
#

its probably the correct thing yeah

vast kestrel
#

Exactly the same as memset/memcpy

fiery turtle
#

i guess i can just add a weak implementation under an ifdef GCC

torpid ferry
#

check that if you build with x86_64-v1 it turns into a single popcount instruction automatically

vagrant hull
#

i can think of running autoconf tests or whatever the cmake equivalent is

vagrant hull
#

compiler-rt as provided by llvm is annoying to use and not gcc friendly

#

this is just dump in the source tree and forget

fiery turtle
#

Instead of a call to this

vagrant hull
#

yeah i am not sure if there is a way to do that with gcc natively that isn't a hack

fiery turtle
#

unlucky ig

fiery turtle
#

like ship my own

vagrant hull
#

what is the use case exactly?

#

the correct solution would be for whatever kernel using uACPI to use cc-runtime or link with libgcc/compiler-rt

fiery turtle
#

i dont want people to copy paste this cc-runtime thing every time

#

its very annoying

vagrant hull
#

as i said

#

or libgcc/compiler-rt

fiery turtle
#

does the default libgcc for 64 bit ship it?

vagrant hull
#

it should

fiery turtle
#

hmm

vagrant hull
#

maybe it depends

#

on whether the target needs it

#

for base x86-64 i assume it has it

#

since popcount isn't guaranteed to exist

#

take libgcc.a and check

#

i checked

#

it has it

#
_popcountsi2.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <__popcountdi2>:
   0:    f3 0f 1e fa              endbr64
   4:    48 ba 55 55 55 55 55     movabs rdx,0x5555555555555555
   b:    55 55 55 
   e:    48 89 f8                 mov    rax,rdi
  11:    48 d1 e8                 shr    rax,1
  14:    48 21 d0                 and    rax,rdx
  17:    48 29 c7                 sub    rdi,rax
  1a:    48 b8 33 33 33 33 33     movabs rax,0x3333333333333333
  21:    33 33 33 
  24:    48 89 fa                 mov    rdx,rdi
  27:    48 c1 ef 02              shr    rdi,0x2
  2b:    48 21 c2                 and    rdx,rax
  2e:    48 21 c7                 and    rdi,rax
  31:    48 01 fa                 add    rdx,rdi
  34:    48 89 d0                 mov    rax,rdx
  37:    48 c1 e8 04              shr    rax,0x4
  3b:    48 01 d0                 add    rax,rdx
  3e:    48 ba 0f 0f 0f 0f 0f     movabs rdx,0xf0f0f0f0f0f0f0f
  45:    0f 0f 0f 
  48:    48 21 d0                 and    rax,rdx
  4b:    48 ba 01 01 01 01 01     movabs rdx,0x101010101010101
  52:    01 01 01 
  55:    48 0f af c2              imul   rax,rdx
  59:    48 c1 e8 38              shr    rax,0x38
  5d:    c3                       ret```
fiery turtle
#

i see

vagrant hull
#

fwiw mlibc also depends on a few libgcc functions and we are certainly not having it ship weak versions of them just to attend those who do not wanna link against a libgcc equivalent

torpid ferry
#

just only have the naive one, popcount won't ever be a perf bottleneck there

fiery turtle
#

Fair as well

vast kestrel
#

If the compiler is smart enough it will recognize what you do and optimize it :^)

rustic compass
#

also if it becomes a problem maybe use a function pointer stored in a mut static and update it at first run to call the software emulation or the hardware instruction

#

unless the call overhead becomes even more problematic

fiery turtle
#

Call overhead is definitely more expensive

fiery turtle
#

Okay here are my plans for thread safety of (namespace vs interpreter):

  • the namespace and modification of nodes is guarded by a rw mutex lock
  • interpreter always takes the write lock (because it's allowed to modify the namespace and randomly update nodes from AML)
  • (public api for) iterating the namespace, finding a node etc takes a read lock
  • iterating the namespace publically will skip temporary nodes (created inside methods)
  • getting the object from a namespace node directly is not allowed. uacpi_eval() must be used, which takes the read lock, makes a deep copy, then returns the object
  • updating a namespace node from public api will be done via uacpi_namespace_node_update(), which will take the write lock
#

this is the biggest part that needed thread safety, the rest should be easier

#

getting the object from a namespace node directly is not allowed. uacpi_eval() must be used, which takes the read lock, makes a deep copy, then returns the object
Although this could be fine as long as reference chain is incremented with the write lock taken

#

it is theoretically possible to make it way more granular and get rid of the GIL, but that would increase memory overhead per node 2x and code complexity by an order of magnitude

#

so im definitely not doing it now, not for 1.0 anyway

#

maybe if i have infinite time on my hands at some point

wind fiber
#
ret = uacpi_reboot();
if(uacpi_unlikely_error(ret))
    infoLogger() << "thor: ACPI reset failed: " << uacpi_status_to_string(ret) << frg::endlog;

returning ACPI reset failed: not found in qemu. Known? @fiery turtle

#

but I'd assume this should just workโ„ข๏ธ in qemu

fiery turtle
wind fiber
#

nope

#
tools/host-qemu/bin/qemu-system-x86_64 -s -m 8192 -name 'Managarm x86_64' -enable-kvm -debugcon stdio -cpu host,migratable=no -smp 4 -device piix3-usb-uhci,id=uhci -device usb-ehci,id=ehci -device qemu-xhci,id=xhci -drive id=boot-drive,file=image,format=raw,if=none -device virtio-blk-pci,drive=boot-drive -netdev user,id=net0 -device virtio-net,disable-modern=on,netdev=net0 -vga vmware -device usb-kbd,bus=xhci.0 -device usb-tablet,bus=xhci.0 -chardev file,id=ostrace,path=ostrace.bin -device dmalog,chardev=ostrace,tag=ostrace -chardev file,id=kernel-profile,path=kernel-profile.bin -device dmalog,chardev=kernel-profile,tag=kernel-profile -chardev file,id=kernel-alloc-trace,path=kernel-alloc-trace.bin -device dmalog,chardev=kernel-alloc-trace,tag=kernel-alloc-trace -chardev socket,id=gdbsocket,host=0.0.0.0,port=5678,server=on,wait=no -device dmalog,chardev=gdbsocket,tag=kernel-gdbserver -chardev socket,id=posix-gdbsocket,host=0.0.0.0,port=5679,server=on,wait=off -serial chardev:posix-gdbsocket
#

that's the full qemu command

fiery turtle
#

i just booted astral like yesterday and reboot definitely worked

#

so it must be one of these command line options

wind fiber
#

oh it works (with the ps2 reset meme)

#

shutdown works fine btw

#

and the prepare to enter S5 thing no issues on that either

fiery turtle
#

yeah definitely works on astral

#

can u try trimming this command line

wind fiber
#

sure

fiery turtle
wind fiber
#

trimmed to nuke all the gdbsocket memes

#
tools/host-qemu/bin/qemu-system-x86_64 -s -m 8192 -name 'Managarm x86_64' -enable-kvm -debugcon stdio -cpu host,migratable=no -smp 4 -device piix3-usb-uhci,id=uhci -device usb-ehci,id=ehci -device qemu-xhci,id=xhci -drive id=boot-drive,file=image,format=raw,if=none -device virtio-blk-pci,drive=boot-drive -netdev user,id=net0 -device virtio-net,disable-modern=on,netdev=net0 -vga vmware -device usb-kbd,bus=xhci.0 -device usb-tablet,bus=xhci.0
fiery turtle
#

in qemu its iffed under LPC

wind fiber
#

are we missing some -m flag?

fiery turtle
#

good question

wind fiber
#

yes

#

adding -M q35 makes the issue go away

fiery turtle
#

yeah its only created for Q35

wind fiber
#

aha

#

good to know

#

(also good to know that ahci breaks on q35 meme)

#

not that that's used

#

but the driver dies

fiery turtle
#

i dont know why tho

#

maybe backwards compat

wind fiber
#

yeah maybe

#

astral indeed passes -M q35

fiery turtle
#

ye

wind fiber
#

so I'll propose that Managarm does the same

fiery turtle
#

Looks like that enables hotplug and all sorts of things on qemu

#

ECAM as well

wind fiber
#

spicy

fiery turtle
#

i think we should pass it in managarm ye

#

CPU hotplug support in managarm when

wind fiber
fiery turtle
#

tbh that shouldnt even be that difficult

#

hotunplug on the other hand..

wind fiber
#

just yeet it

fiery turtle
#

what could go wrong

wind fiber
#

worst case it asserts somewhere

#

sounds like average AssertOS thing

fiery turtle
#

lol

median crest
#

Assert(!unplug);

fiery turtle
#

this is probably true unironically

#

it would assert that some task hung or whatever

wind fiber
#

just unplug the CPU with the unplug thread running 5head

#

can't assert if the thread that's checking it is gone

kind mantle
#

When would CPU hotplug even happen?

#

What's it used for?

deft canopy
# kind mantle When would CPU hotplug even happen?

I think it might be used in large clusters? but I'm not really sure
my plan for OpenItanic, and subsequently IFOS, is to provide a CPU hotswap mechanism if ACPI properly allows it (I am yet to fully understand ACPI, but one day I will)
the hotswap would be primarily for testing the limits of the processor interconnect, but might be useful if I'm running tests and have a part fail

kind mantle
#

Interesting

#

I've thought of what BadgerOS might do about it and I'm not supporting it for now but...

#

... the current codebase is very much lenient to such shenanigans happening, if you use the proper mutexes.

kind mantle
#

lol

vast kestrel
#

Alot of auto-scaling will allow for cpu hot plugging

#

Sometimes even supporting transferring the VM to a larger machine, which then will add it's cores as well

fiery turtle
wind fiber
#

Lol

#

Still good to do correctly regardless

fiery turtle
#

yeah this mostly matters for quirky laptops

median crest
#

In vms at least you can use the hypervisors for some services like monotonic clocks that dont get out of sync with the hot plug (cough tsc sucks)

vast kestrel
#

You don't bad mouth tsc it's awesome

fiery turtle
#

finally went ahead with this change

#

also decided i'd expand on how to treat timeout

#

(well this change is part of a giant thread safety pr im working on)

craggy epoch
#

How usable is uACPI as of now? I saw that the repo says it isn't production ready because of some thread safety stuff but is it close if it's only used in a single thread?

hasty plinth
#

Its in a good enough state that plenty people here have used it for various things

fiery turtle
#

everything is implemented and stable

craggy epoch
fiery turtle
#

there are rust bindings in pins

#

albeit a bit unfinished in some places

craggy epoch
#

I'll take a look and maybe see if I can help with that as way to give back.

torpid ferry
fiery turtle
#

lol thanks saga

craggy epoch
fiery turtle
#

thats because the reference implementation doesnt try to follow the real reference implementation which is NT

craggy epoch
#

How can you when it's closed source?

fiery turtle
#

and uacpi is built as if NT is the reference implementation

fiery turtle
craggy epoch
#

That makes sense. Since that's what it looks like the FW vendors seem to target. I honestly hate ACPI but what I hate more is all the ARM and RV boards that don't provide it and go off and use other things like SMC and SBI.

fiery turtle
#

TLDR: feed arbitrary AML to windows and see how it works with it

#

windbg has a way to enable tracing for every aml opcode that is executed

#

so u can see what it outputs at any point

#

!amli set traceon dbgbrkon errbrkon spewon;g

craggy epoch
#

That's interesting. I assume that's all done in a VM so the firmware can be messed around with. So just a question if you don't mind, how does Linux handle firmware that's made for Windows if it uses ACPICA which doesn't follow Windows?

torpid ferry
#

poorly, or not at all

fiery turtle
#

acpica had to adapt a lot of workarounds throughout its lifetime

#

some things still dont work

torpid ferry
#

generally it just screams loudly on dmesg but it works anyways

fiery turtle
#

it tries to pretend to do things like nt with hacks

#

but its fundumentally incompatible

craggy epoch
#

Thanks for answering all my dumb questions and you guys are all awesome for making this project! It is much needed.

fiery turtle
#

people have collected tons and tons of bug reports throughout the years where most important incompatibilities have been fixed with hacks in acpica, the rest are small things that generally are not that imporant

fiery turtle
#

if ur interested to see some examples look at my readme

craggy epoch
#

Will do!

vale isle
#

maybe in the userspace

fiery turtle
#

its 100% possible to shove it into the kernel directly, especially since a lot of public uacpi api mimics acpica, but there are thousands of files that use acpica api directly, so all of those would need to be rewritten

#

so its just a lot of work

north holly
#

What if you just