#uACPI - a portable and easy-to-integrate ACPI implementation
1 messages · Page 67 of 1
i send it via serial after i finish rn
how do i make a flamegraph from your output btw
i dont do it by hand, kcachegrind does that sort of stuff
and lots more
oh it's an app
this is a big wheel i didnt want to reinvent
i tought you had a script
yeah, an open source program
the serial port output just redirects to a file called callgrind.out and that can parse it
back later, work time
actually started thinking about this too when I saw the mention of rapid free and allocation of small things
esp because zig has a lockless thread safe arena in the std
(thread safe as long as it's backing is anyway)
i mean you could also try allocating less 
allocate one huge arena and divvy it out
dont
I mean I give uacpi it's own standalone buddy arena anyway
big allocations are harder to cover
imo you can get more from a better interpreter and better allocator usage than you can from a better allocator
optimizing acpi interpreters for speed is useless
it's better to optimize for stability
that is, less code that can break and simpler code
100%
and the warmup path is even more useless
I don't really care how long it takes so long as it's not noticeable
its already not
in the grand scheme of things uacpi startup is a fraction of a hundredth of a percent of startup time (and startup time is already under 2s and dominated by a pci scan)
great news for uacpi and for its users
having fun? 😊
seeing proper profile data for my os was a huge eye opener, I increased my performance 10x
i'll re-enable the log instrument
8% of your time spent logging
nah, that's just flanterm
yes .flanterm from your log function
You should try sampling rather than instrumenting
wdym sampling?
you sure?
sampling
sampling doesn't give you a full picture only a sample data set, a subset
yes but instrumenting is slow
and?
Doesn't necessarily represent real runtime
if he's using my code it's not that slow
I'd say it's best to mix both
everything is equally slower
so the percentages are correct
all the profiler hooks are O(1) or close to
It's not just about the percentages but finer CPU details
you could mix both just don't profile your sampler
Yeah or like do a sampled run and an instrumented run
thats a lot of putchar
yeah
Me when the entire profile is logging
Maybe disable logging completely when profiling?
true
and here it is
and my alloc seems pretty good rn
there are a lot of redudant deep copies in the interpreter that cause extra allocations
but they arent easy to get rid of
yes they are
since id need to know whether an object is a prvalue or not
are u an aml expert now lmfao
but tbh even as is it gets 10M ops/s
They’re honestly pretty easy to deal with once you look at them the right way. Most of those deep copies aren’t fundamentally required—they’re usually just there for safety or convenience. In a lot of cases, you can replace them with shallow copies, references, or move semantics without changing behavior.
which is miliseconds even on most bloated aml
most bloated aml is like maybe 30k ops total
lol
go fix them make no mistake
also switching to computed gotos is a possibility for increasing perf
I dont think computed gotos even do anything nowadays
nah i saw some example recently where they had some simple bytecode interpreter
and computed gotos boosted perf by a lot
it was all tail call based
was it a recent example
cuz I think I know what you're talking about
but that post is pretty old
maybe
right now when microcode ops call into C it uses a dispatch table of function pointers
ah yeah thats probably not good
yeah
@fiery turtle Here's the ACPI dump from the CIX P1
thanks
cool arm with proper acpi
how it should always have been
looks like power state transitions still require prorietary drivers tho
i thought that on arm this was done with psci?
which is as much of a proprietary driver as SMM
yeah maybe idk, its not indicated by acpi
the arm equivalent(ish) of smm has a defined api boundary
you use it for AP startup and power management and shit
Is it possible to invoke a psci via aml even
like technically acpi has a proper power management spec for reduced hardware
but its not used here
Smi you can cause it's port Io
how does that work
But isn't psci done via some special opcode
actually sounds interesting
via a generic address space register
it can be any address space they want
hmm does linux support that
yeah
also how does the whole interface work, anyway
i wonder if you could use this to implement sleep states etc on apple (where you dont have psci)
u read the magic values to write into the register from the state object, e.g. _S5 for state 5
then run _PTS, then write them into the register
ok sure but when does native code execution enter firmware
multiple ways
on x86 this works with smm
but idk if there is a "plz jump to physical address 0x4141424243434444 with no paging now" aml op
generic address register has a way to specify hardware-specific address space, which could mean call into firmware with that instruction
ok sure but that would require kernel support anyway
yeah ofc
there isnt anything generic ig?
nothing to call into the psci i dont think
but i could be wrong
these are the defined address spaces
#define ACPI_AS_ID_SYS_MEM 0x00
#define ACPI_AS_ID_SYS_IO 0x01
#define ACPI_AS_ID_PCI_CFG_SPACE 0x02
#define ACPI_AS_ID_EC 0x03
#define ACPI_AS_ID_SMBUS 0x04
#define ACPI_AS_ID_SYS_CMOS 0x05
#define ACPI_AS_ID_PCI_BAR_TGT 0x06
#define ACPI_AS_ID_IPMI 0x07
#define ACPI_AS_ID_GP_IO 0x08
#define ACPI_AS_ID_GENERIC_SBUS 0x09
#define ACPI_AS_ID_PCC 0x0A
#define ACPI_AS_ID_FFH 0x7F
#define ACPI_AS_ID_OEM_BASE 0xC0
#define ACPI_AS_ID_OEM_END 0xFF
but i mean psci eventually does some mmio writes and stuff anyway right
that could be expressed in aml
well usually you arent allowed to access that
because the cpu resets into the secure monitor
so if you could control the reset vector that would be bad™
but anyway i dont think there is even any way to make acpi sleep work on arm
other than with psci
although i wonder if you could hack together an acpi table that would make acpi sleep work on m1
would be so jank
does apple stuff also rely on that for shutdown?
apple has magic drivers
wdym
apple doesnt use psci at all
and you cant make it work on apple hw without losing virt
which is more important
I guess that should be easy to express in aml then?
Lol
U mean it needs el2 or smth?
psci needs either el2 or el3
virt needs el2
and you cant use either for both at once
oh and apple doesnt implement el3
Why does virt need el2
thats just how virt works on arm
x86 virt requires you to be outside of a vm too
Yeah so you can run the kernel in el2 and run aml there too
And virt runs in el1 no?
yes but i dont know if linux can do acpi suspend on arm at all tbh
Well at least shutdown would be nice
they have some kind of hack that makes it work without acpi
and without psci
ah its not a hack
i think the jank is that it cant do suspend or smth idr
is there like an adhoc driver for that in asahi
its upstream
for poweroff at least
i dont think you could make that really work with aml tbh
and even if you could, aml is shit as a programming language lol
Can you show it
well so its two drivers
driver one does a bunch of shit and then this: ```c
static int macsmc_power_off(struct sys_off_data *data)
{
struct macsmc_reboot *reboot = data->cb_data;
dev_info(reboot->dev, "Issuing power off (off1)\n");
if (apple_smc_write_u32_atomic(reboot->smc, SMC_KEY(MBSE), SMC_KEY(off1)) < 0) {
dev_err(reboot->dev, "Failed to issue MBSE = off1 (power_off)\n");
} else {
mdelay(100);
WARN_ONCE(1, "Unable to power off system\n");
}
return NOTIFY_OK;
}
Its good you just have to know what code to avoid writing to prevent acpica from segfaulting 
lmfao
Is that just an mmio write?
apple_smc_write_u32_atomic is ```c
int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, const void *buf, size_t size)
{
guard(spinlock_irqsave)(&smc->lock);
u8 result;
int ret;
u64 msg;
if (size > SMC_MAX_SIZE || size == 0)
return -EINVAL;
if (smc->boot_stage != APPLE_SMC_INITIALIZED)
return -EIO;
if (!smc->atomic_mode)
return -EIO;
memcpy_toio(smc->shmem.iomem, buf, size);
smc->msg_id = (smc->msg_id + 1) & 0xf;
msg = (FIELD_PREP(SMC_MSG, SMC_MSG_WRITE_KEY) |
FIELD_PREP(SMC_SIZE, size) |
FIELD_PREP(SMC_ID, smc->msg_id) |
FIELD_PREP(SMC_DATA, key));
smc->atomic_pending = true;
ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, msg, NULL, true);
if (ret < 0) {
dev_err(smc->dev, "Failed to send command (%d)\n", ret);
return ret;
}
while (smc->atomic_pending) {
ret = apple_rtkit_poll(smc->rtk);
if (ret < 0) {
dev_err(smc->dev, "RTKit poll failed (%llx)", msg);
return ret;
}
udelay(100);
}
if (FIELD_GET(SMC_ID, smc->cmd_ret) != smc->msg_id) {
dev_err(smc->dev, "Command sequence mismatch (expected %d, got %d)\n",
smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret));
return -EIO;
}
result = FIELD_GET(SMC_RESULT, smc->cmd_ret);
if (result)
return -EIO;
return FIELD_GET(SMC_SIZE, smc->cmd_ret);
}
EXPORT_SYMBOL(apple_smc_write_atomic);
lol no
its a mailbox
there is a whole ipc-y system used to talk to devices
which is involved here
Ah
the smc also owns the rtc
and apple_rtkit_send_message is another lots of code: ```c
int apple_rtkit_send_message(struct apple_rtkit *rtk, u8 ep, u64 message,
struct completion *completion, bool atomic)
{
struct apple_mbox_msg msg = {
.msg0 = message,
.msg1 = ep,
};
if (rtk->crashed) {
dev_warn(rtk->dev,
"RTKit: Device is crashed, cannot send message\n");
return -EINVAL;
}
if (ep >= APPLE_RTKIT_APP_ENDPOINT_START &&
!apple_rtkit_is_running(rtk)) {
dev_warn(rtk->dev,
"RTKit: Endpoint 0x%02x is not running, cannot send message\n", ep);
return -EINVAL;
}
/*
* The message will be sent with a MMIO write. We need the barrier
* here to ensure any previous writes to buffers are visible to the
* device before that MMIO write happens.
*/
dma_wmb();
return apple_mbox_send(rtk->mbox, msg, atomic);
}
and apple_mbox_send is another screen of code
and its DMA btw
Why is it called an rt kit
i think its like a framework used to do realtime things that apple uses
lol
Framework as in like set of APIs?
seems like its an rtos lol
There's a coprocessor running it?
ofc
Lol
its apple
I guess thats a neat way to do it but
hvc or smc depending - the madt will tell you which
Iirc the iPhone camera runs a separate Linux instance or something?
well its not linux lol
Someone said it literally was Linux
that would be very weird
the touchbar on Macs that have that is just an elongated iPhone

i dont think thats the case on m1
I remember it's the case on some at least
people have gotten Linux running on specifically the touchbar
not the mac itself
the touchbar individually
the touchbar was its own thing yeah iirc
Bruh
Isn't that really increasing the cost for everything
Nintendo did it first in 2006 
dont think so
(probably not first; but before Apple at least)
or not significantly anyway
Whats the cpu in it
its probably some arm thing
I don't remember, I saw that ages ago
Does it run some customized Darwin kernel by default or
i think it was vulnernable to the same bootrom bug as iphone bootroms were lol
I'd imagine so, since it uses iBoot, and that's how they got Linux running on it
^^^
its arm64 too
seems like its based off of watchos??? lol
lol
Yeah it's a constrained Darwin, but I think apple also has another kernel for something which I forgot
Like they have a distinct thing from Darwin that they use somewhere
smc
Secure monitor call
That is extremely disappointing. I wonder if PSCI still works though.
i mean whats the alternative
Some kind of proprietary driver like Qualcomm pulled with Windows for Snapdragon X.
It would fly just fine for a vendor Linux. Android does stuff like that all over the place.
it can be hvc instead btw, if the hypervisor is intercepting it
yeah
all pci stuff is described properly including allowed bar ranges etc tho
once you have wafer space adding more logic is free 
He's got a wafer
Is uacpi-rs reasonably up to date and maintained?
might be worth asking in #1287451030241542205
using qcachegrind
and you have to output the correct log syntax
@fiery turtle if i want to use uAcpi in userspace, i would have to use ioperm, but where should i use it?
i could do it in the io_read and write ops
and that should be pretty straightforward, but i am worried it might cause slowdowns
should i just use ioperm with the base?
i am worried it won't work with the offset later
i mean in the tss io bitmap just set bits corresponding to the ports in range [base, base+len)
I just iopl 3 it
💀
for the acpi server might as well tbh
but you can probably refcount it in userspace, and call your kernel helpers to enable/disable it in tss
given aml can just request arbitrary ports anyway
from io_map/io_unmap
and unmap? just remove the perms for the handle?
yeah
thx
Or you can just call kernel
like io is slow anyway so an extra roundtrip won't be noticeable I guess
you also need to think about pci discovery and stuff probably
i'm gonna use messages + a dedicated pci service for that
i already have a messaging interface done
like last week was the init server week
this was in the works for at least 1 year
lol
i have a central service that handles registration of the others
and you can call that to get the other services tid and port to send messages to
no, I mean what's your ipc model, out of curiosity
not the discovery
(also, I'm thinking I can walk away from having a central discovery mechanism in my os)
i just made a custom message struct and use this to send messages between threads, messages are stored in a server queue and routed accordingly
this struct could prob be reduced tbh
and in kernelmode its an unbounded message queue?
yeah it's unbounded
so is it async send sync receive like mine?
i should probably put limits on it tho
ye
I've been telling that to myself for the past 3 years and haven't gotten to it yet lol
XD
@calm latch what would be the best method for a per thread IOPB?
or per process
copying the iopb array would be expensive, no?
I guess just allocate a tss when you enable it
so a TSS per thread?
idk
CoW it if you want
I'd imagine per-process would be problematic because you need to store the kernel stacks somewhere
I guess you could allocate one per cpu for each process and rotate through them though
or given that io ports are rarely used today have a syscall for io port reads
just point the rsps and ists to a per cpu one
but then you'd be copying the bitmap
no?
the tss is still per process
if you do per process
yeah, but what I mean is that you need to allocate tss per cpu per process
iopl is removed with FRED
I can just not support FRED then 
or support the tss bitmap
extra work anyway
you can emulate iopl by just storing an all ones bitmap in the tss
I can also catch gpfs
no, if I'm doing it, I'm doing it properly, and with capabilities and stuff, and the proper bitmap
capabilities for everything is very nice anyway
like you don't have to do anything, and your system has suddenly got very good access control infrastructure
you can also have a cap that gives access to all ports
yeah, but that's boring
because otherwise it's very nice for drivers
especially if (when) I end up supporting iommu
(like as a whole)
I already have capabilities for interrupts, I'm planning to implement capabilities for timers and physical memory
is dis fast
idk
i never pay attention to my benchmarks unless they become abominable
which is less frequent these days
this is emulated x64 on apple silicon m4
TCG is usually an order of magnitude slower so good job
i think mine will work even better when i move uacpi to userspace
qemu tcg or whatever the apple compat layer thing is? i keep hearing people say they have one but idk how good it is lol
rosetta
?
but that's for running native applications
i belive it does aot x86->arm64
at least to some degree, idk how much you can really translate ahead of time
I think it also links the transpiled apps against native libs
such that for example the gpu driver etc. runs natively
@fiery turtle is the string passed by uacpi_kernel_log changed after the function returns?
so is the lifetime limited to the function invocation?
yes
if you have formatted logging probably not tho
ah yeah
downgraded to an object 
anyway,
how should i handle if the user of uacpi-rs hasnt implemented memory map/unmap as there isnt a status return
in for-5.0 there's a UACPI_MAP_FAILED
sorry idk what that means
return null?
just make uacpi logs map to the log crate ngl
i assume its talking about the non-printf version
lol
tbh i'm not really a fan of this, it locks you into a somewhat specific logging framework even if you dont need/want one
i wasnt referring to you lmao
currently still on 3.2 should probably update
on older versions returning NULL is treated as an error
@pallid lava btw why did u need to trace ec events in linux
i wanted to know whatever is being called on my laptop
so when i get to write an ec driver i can make sure i am not reading garbage from the ec
Ah ok
so uh
should there be an _EXX or something similar in \_GPE for the EC's GPE?
i am trying to install the gpe handler and i am getting not found error
nope
_EXX are run by uacpi automatically
just use this as an example
okay, yeah, my issue is with uacpi_install_gpe_handler, that's the thing that is erroring
did u verify that you're passing the right index?
Nvm, I was not calling finalize_gpe..., and i was supposed to pass null as first argument to install and enable handler
Now everything works 
yeah it expects a GPE device, which is either \_GPE or a custom installed GPE block
or NULL which implies the former
cool cool
got ec events and method dispatch working 
as a fun fact, the ec apparently intercepts some fn + something keys in my laptop
the arrow keys for controlling the backlight brighness of the keyboard, and f7/f8 for the display backlight brighness
however, the aml code for the keyboard does not do anything unless you discover the wmi object that controls the keyboard and other memes and you initialize it (aka call some magic function with some magic values)
Yeah wmi is a funny thing
and after you initialize it
that thing only sets a variable to 1, which is tested in the _Qxx method, and if set, does a notify() on the wmi object
Ye
and then you have to handle that natively and call some other magic method and shi
That's pretty normal
Yeah
for the display brightness it gets a bit more weird
because it complains about objects that do not exist
Lol
it complains about \blablabla...VGA.EDP
Does it do that on Linux
letme check
extremely epic one
May 09 21:04:25 AtiePC kernel: ACPI BIOS Error (bug): Could not resolve symbol [^PCI0.GPP0.PEGP.EDP1], AE_NOT_FOUND (20251212/psargs-332)
May 09 21:04:25 AtiePC kernel: ACPI Error: Aborting method \_SB.BRTN due to previous error (AE_NOT_FOUND) (20251212/psparse-529)
May 09 21:04:25 AtiePC kernel: ACPI Error: Aborting method \_SB.PCI0.SBRG.EC0.QLIB due to previous error (AE_NOT_FOUND) (20251212/psparse-529)
May 09 21:04:25 AtiePC kernel: ACPI Error: Aborting method \_SB.PCI0.SBRG.EC0._Q17 due to previous error (AE_NOT_FOUND) (20251212/psparse-529)
May 09 21:04:26 AtiePC kernel: ACPI BIOS Error (bug): Could not resolve symbol [^PCI0.GPP0.PEGP.EDP1], AE_NOT_FOUND (20251212/psargs-332)
May 09 21:04:26 AtiePC kernel: ACPI Error: Aborting method \_SB.BRTN due to previous error (AE_NOT_FOUND) (20251212/psparse-529)
May 09 21:04:26 AtiePC kernel: ACPI Error: Aborting method \_SB.PCI0.SBRG.EC0.QLIB due to previous error (AE_NOT_FOUND) (20251212/psparse-529)
May 09 21:04:26 AtiePC kernel: ACPI Error: Aborting method \_SB.PCI0.SBRG.EC0._Q17 due to previous error (AE_NOT_FOUND) (20251212/psparse-529)
during namespace initialization both linux and uacpi complain about some other objects not existing
PCI errors
reminds me that iirc on my laptop the ec fn keys were interacting weirdly with my ps2 driver at some point so then it stopped working or something, idr if that was with the old bad osdev wiki driver tho or the new better one that's based on linux's
or it could have been qacpi weirdness somehow as there were also the spurious power button events during boot
Lmao
Iirc u fixed those power button events right
Which laptop is this btw
I don't think they actually got fixed, I did remove the ec clearing code that was also causing qookie's laptop to hang there but I think they did still happen when I last tried (I just though they were fixed because they didn't happen for a decent amount of boots)
otoh i have backlight methods in aml
the standard ones, specified in the acpi specification appendix
i have to see whether they work
Ah
Thats kinda rare
ASUS TUF Gaming A15 FA506NC
yeah those usually have shit aml
lol
i remember when i bought the laptop, i thought it would be a good idea to install the asus linux kernel
Thats a thing?
it's a community kernel
Huh lol
after rebooting to it, the keyboard backlight stopped working after the firmware phase
Lol
i was ultra panicking
i tried everything to get them back to work, including trying to write values to the sysfs attributes for the backlight
it resulted that idfk what they had done but their wmi driver was nuts
after cross referencing the mainline kernel source code with what the writes to the attributes should do
then i got back to an original kernel and the keyboard backlight started working again
those were the 2 scariest days in my life because i had just bought the laptop and i tried everything in whatever forum i found, including pressing the power button for 40 seconds to clear the ec, which i am not still sure whether that works
on my laptop pressing fn+f2/f3 (brightness down/up) causes linux to log unknown keys in dmesg (the brightness control does work so it's a little bonus)
[85585.698385] atkbd serio0: Unknown key pressed (translated set 2, code 0xab on isa0060/serio0).
[85585.698396] atkbd serio0: Use 'setkeycodes e02b <keycode>' to make it known.
[85585.781303] atkbd serio0: Unknown key released (translated set 2, code 0xab on isa0060/serio0).
[85585.781310] atkbd serio0: Use 'setkeycodes e02b <keycode>' to make it known.
[85586.546999] atkbd serio0: Unknown key pressed (translated set 2, code 0xab on isa0060/serio0).
[85586.547011] atkbd serio0: Use 'setkeycodes e02b <keycode>' to make it known.
[85586.673181] atkbd serio0: Unknown key released (translated set 2, code 0xab on isa0060/serio0).
[85586.673187] atkbd serio0: Use 'setkeycodes e02b <keycode>' to make it known.
btw, has anyone here got sleep working?
i wonder if it would be possible to have the display working after waking up without having to write native video drivers, or only using aml methods
@north holly and @calm latch did
oberrow had it working on real hw
but no display, that requires full gpu re-init
I mean me too, but I didn't have GPU drivers
then the big regression™ broke everything

in theory sleep code still is correct
so you know you're awake via serial or some other mechanism, that is not by video?
but the rest of the kernel is the reason it broke
i know it woke up because i made it shutdown after wake
oh okay
speaking of kernel that project has been dead for a good while
i'll work on it soon
u need to restore pci state too
which was fun to do
D0uninitialized by beloved
it clears all BARs etc
i guess that it is not possible to use the boot services after waking up
well 
what would you even use them for
Yeah, I have 2 PCs with serial out, and my kernel had woken up and printed so on serial
video mode i guess
I reuse the same trampoline as for my SMP init
yeah, exactly that
ah
to get a fb with gop
but in that case the firmware would have to reinitialize the video card too
but yeah no u need suspend/resume callbacks for all drivers
yeah
on qemu u can make a bochs vbe driver to restore the fb fwiw
yeah but real hw is more exciting
qemu wake after suspend wont work
because u havent upstreamed the seabios fix
or rather, it disables ecam iirc
oh yeah forgot about that
wait, whats the problem with it
kinda related to this is the better trampoline that's supposed to be entered at protected mode also entered at real mode? or is it actually protected mode, that's what I have been assuming when writing the trampoline code
ECAM is disabled after wake
ECAM isn't restored
or well it is but something else prevents it from being restored
it is actually protected mode
but idk if any firmware supports that trampoline
like seabios already has code for handling s3 wakes
how did they forget that, or qemu has had a nasty regression
welp
if anyone wants to takeover it's a really simply patch
the seabios mailing list has very low traffic
(it's a lot of work because it interrupts my hyperfixation)
you could get it upstreamed in a few days
iirc the problem wasn't that, it was that it left the mmconfig pointing to the ecam space and then after resuming the pci accesses it does (like enabling the ecam itself) try to use the mmconfig that isn't enabled
seabios should be easy to upstream yeah
oh yeah maybe
it uses ecam to enable ecam
which fails

@north holly can u post the patch here
i don't think i have it anymore
u would have to search the seabios mailing list for it
I think this is enough for it
make_bios_writable?
lgtm
it's in ROM
it has to do with being able to write the variable
to modify the variable, right
ye
i think they had a problem with just doing that in a random place if u wanted to find my post on the mailing list
before u submit the patch
yeah mainly just my own patch skill issues
I think the comment about the bios readonly doesn't really even apply here as the commented out code wasn't there originally to begin with (and its made read-only later on in the same function anyway)
i would've followed up but i was thousands of KMs from home
and forgot to when i got back
would be nice if someone picked that up
sure would
sadge
maybe u need some igpu pre-init before u can use it or smth
or hook the notify and do something
what an issue
I think it comes from this? https://github.com/joncampbell123/dosbox-x/issues/6260
Question I and some others are wondering if some developers here could help implement ACPI for DOSBox-X via https://github.com/uACPI/uACPI if possible. ACPI is currently a stub, as you know, and it...
I think the question was if it works with ACPI 1.0
stalking that person's profile
They just use gcc, so I guess uACPI could be compatible?
im not sure it will compile in 16 bit mode but who knows
why wouldn't it?
UACPI_POINTER_SIZE checks for phys_addr etc
16 bit gcc doesnt support u64?
idk if 16 bit supports them
it does?
no idea
honestly im not sure how that would even work considering the DSDT is definitely larger than 64k
oh no, uacpi is AI tainted now

so u need segment support also
(sorry, I can't get over openslopware)
https://github.com/uACPI/uACPI/issues/153 lmfao, I wouldn't have understood what this is about
yeah lol
this is for open watcom
yeah
but clanker is right about other aspects
like 16-bit aml interpreter makes no sense
u literally cant even read the entire dsdt in one segment
Is their thing 16 bit?
i thought so since its DOS
maybe its fine then
Like if they're talking about windows, maybe they target i386 or something?
They're using uint64_t's in their latest commit https://github.com/joncampbell123/dosbox-x/commit/de5b0961a4b11243d54c6977e6a5530cf0f90d19
whatever is this
No, it's an emulator?? https://dosbox-x.com/wiki/#Home
So maybe they do want to generate AML or something
I'm confused
who knows what they want lmfao
I think I'm gonna go back to doing what I was doing before, which is figuring out how tf linux manages its io bitmap/tss on x86...
i am doing lazy tss rn
works fine
wdym by that
do you just copy all 16kb of memory?
8kb*
basically i have a per core tss, that is used by all the normal processes
then, if a thread needs an io bitmap
the tss gets cloned only for that thread
https://elixir.bootlin.com/linux/v7.0.5/source/arch/x86/kernel/process.c#L446 linux seems to just memcpy it...
my approach is faster and more reliable tbh
i just have a set of common pointers
that all the TSSes use
for each core
and the tss does not need to be copied
so it's faster
but that's the easy part
and if the thread does have one, the scheduler loads that one
if it does not, it just uses the cpu one
when you take the permissions away
I don't think it gets cached
like you don't need to reload it since the cpu looks it up on every access iirc
hmm
i change the gdt entry every time i have to switch it
so i tought i had to reload it
Or I can just make it a syscall 
wdym
like not bother with tss and just call the kernel to i/o in ring 0
💀
Osdev forums have a genius solution https://f.osdev.org/viewtopic.php?t=21251
I'm gonna steal it
and this shit should be trivial to do
omg wtf
I kinda didn't understand it but
W/e I guess
Not that I care about Userspace pio
Just abuse shared memory to have the same bitmap inside different per-CPU TSS instances
But the tss mask is needed per thread no?
I'd do it per process
Because per-thread makes no sense
Even so, the process can migrate between cpus right
Yeah, and the process can have more than 1 thread running on more than 1 CPU at any given time
So how do u sync stuff
and that's why you need per thread
lol
if you don't wanna nuke stacks
No
So my plan is to allocate 4 page frames virtual window, where the first page will be the per-CPU stuff, the two pages in the middle will be swapped in the page tables between the threads/processes (so the TSS stays in the same place in virtual memory, but the underlying memory changes between the processes), and the last one would also be the same (for the Intel's skill issue 0xFFFF terminator byte)
Crazy stuff
So, the two pages in the middle (which have the actual bitmap) have the same shared underlying memory, so when you change per-process bitmap, it changes in all of the TSSs because it's basically shared physical memory, just mapped at different virtual memory location
And switching is not too bad since you're just changing two leaf page table entries
ah wait, 4 pages is the full TSS you mean
1 page for TSS (per-CPU), 2 pages for the bitmap (64K entries, 8KB of RAM per-process), and extra page (which will 1 page shared between everyone) for the meme in the screenshot
Just casual osdev forums gem
So you switch the bitmap by fiddling with page tables on task switch
Also, while I'm at it, I might as well fix my stack allocation code and add guard pages as well...
I think I also have all the logic in kernel to do this already
That scheme sounds way more convoluted than simply loading another tss
No
It's very simple
The only issue is that I need to decide if I want to trap GPFs and have a small instruction decoder, or to IPI other cores...
The first option sounds like an absolute nightmare on x86
I think I'll just hijack my TLB shootdown thing for this
It requires process private kernel PTEs
So?
which is not very simple + has design implications on the rest of the virtual memory subsystem
just make an outb syscall tbh
the alternative is a ltr instruction which doesn't have any impact on the rest of the kernel at all
I thought about it yesterday, and didn't come up with any obvious issues
It will be ltr to sometimes change the tss size
what's even the benefit over just ltr in all cases?
That I don't have to allocate a million of TSSes, and syncrhonize them on every bitmap change
Just make it per thread
And that it can be faster
Per thread is complicated
citation needed
With uACPI
I don't buy "it is faster" w/o benchmarks
at least for this kind of thing yeah its dicey
i would really just have an inb/outb syscall tbh, or iopl
You're trading one instruction for extra effort in the VMM
that sounds like it's really not worth it to me
The only extra "expensive" part compared to per-thread TSS is (maybe) swapping 2 pages in the page tables, but userspace stuff becomes a lot easier if it's per-process
iopl doesn't exist if FRED is on so betting on it sounds like a bad idea
the syscall is probably fine
oh right
just trap it with fred
but supporting the bitmap is also not hard
that effort is only there if there are 2 different drivers, using different bitmaps, scheduled on the same CPU one after the other
wdym by "swapping 2 pages"
if you swap pages you need to TLB invalidate
I tried to explain it here
Yeah, swap the PTEs and invlpg 2 pages
No remote shootdowns
uh that becomes hard to reason about
invlpg isnt that cheap right?
I'm aware but if you do it like this you can accessible-but-not-referenced-anymore pages over extended periods of time
Yes, but there's no problem with that
tbh i doubt any of the approaches are meaningfully better
the entire argument is moot until you have benchmarks on the cost of ltr
I bet this scheme is not worth it
But I will ltr anyway
ltr is certainly more annoying
or rather: I bet that it has negative overall impact
Like what this saves me from is trying to figure out how to synchronize multiple bitmaps in userspace
E.g. with deferred work with uACPI/ multithreaded drivers in general
Then my temp mapping thing is screwed as well
for all threads in my thread pool
thread.schedule_job(|| syscall_to_enable_bits())
i would have two tsses, one with all bits set and one with no perms and just switch between the two with ltr tbh
You can just have one tss and slide its size in GDT
But I don't really want iopl emulation
well really youd need two entries anyway
imo iopl is just the better way to solve the problem for the like one driver which needs it
Not if you have per-CPU GDT
encoding a gdt entry isnt free either
(or like you can wrap it with a lock or whatever, since ltr is cached)
a lock is even worse tbh
You're changin a couple of bytes in it
But sure
yeah idk which fields contain the size tbh
Idk either tbh but it doesn't matter
But something something microkernel something something capabilities something something process isolation
I'd just have per-thread bitmaps
which is what Managarm exposes
then you just ltr on task switch
you have a capability for yolo
you are never creating a capability which only lets you do acpi and nothing else
but you don't have uacpi in userspace...
well i dont have uacpi at all
except for switches between tasks with no enabled io ports, for these you just keep a global tss
yeah, ofc
like thats not really a thing in practice
well, for acpi i agree that just iopl-like control is fine but you also need pio for some pcie drivers
its not on the fast path for them though, right?
you need pio for a bunch of stuff on x86
@fiery turtle you shouldnt be using volatile loads when you do sync btw (this is source/mutex.c)
and also cmpxchg_weak is a thing
Like idk, I have ns16550 and PS/2 drivers for example, both of those need 2-4 IO ports, like it would be nice to not have to give them out full iopl
ah ok
how many cycles is in/out stuff?
not in the uacpi atomic bindings
how does it help anyway
many
whast the diff btw
weak is allowed to randomly fail
Like would 200-400 cycles for 2 invlpgs even matter compared to the IO itself?
if you need it to not fail spuriously
(and mind you, only if you have two different servers running on the same CPU)
ah ok basically where u dont expect it to fail
lol no
the really big number is throughput
Also, I don't have PCIDs, so I just TLB flush anyway
(in order: alder lake P, aalder lake E, zen5)
also lol doing an OUT on alder lake causes the JMP unit to do things
i wonder why 
Syscall is also like 50 cycles for the instruction itself + however long the kernel takes to do its stuff
its a lot more than 50 iirc
on linux on arm (apple m1 p core), its 350 cycles end to end so its actually not that bad
i think its a bit more on x86
so actually maybe a syscall is faster
because you gain however much time loading a tss takes
and you lose a few hundred cycles for a syscall which is not that much compared to the actual op
How slow is FP/vector stuff save/restore on x86?
no idea
non-weak compiles to a retry loop where weak sometimes does not need one
so if you do the non-weak version in a retry loop you have nested retry loops
which is unnecessary
makes sense
maybe its relevant for itanium
which is the other non-hw-reduced platform
it's relevant for all ll/sc archs
is itanium one?
idk ¯_(ツ)_/¯
The Intel Itanium (IA-64) architecture does not use the traditional Load-Link/Store-Conditional (LL/SC) paradigm for atomic operations found in many RISC architectures (like MIPS or ARM).Instead, Itanium utilizes a combination of predication, speculation, and explicit, serialized memory instructions within its EPIC (Explicitly Parallel Instruction Computing) design to handle atomic operations and synchronization.
looks like it has cmpxchg in the isa
This is so sad...
The used servers are expensive
(I need to stop geting sad about random things which don't matter)
@fiery turtle What stage of the normal init i have to be to use uacpi_table_find_by_signature?
uacpi_table_subsystem_available()
Well, I've gotten this insanity to work (as iopl emulation for now
)
https://gitlab.com/mishakov/pmos/-/commit/113af29a8ea0eb11ebfbb0ae026e58ed72255a87
What's missing is capability and logic to set/clear the right bits (and i686), which is like nothing
And also I'm missing an invlpg when coming from tlb shoptdown routine
isn't that heavily dependent on what hardware you're accessing with it
my understanding is that even in the best case scenario its many
Does uacpi_namespace_node never get freed after getting it in uacpi_namespace_for_each_child?
I need it for a IPC thing where the drivers can request interrupts from my server with uACPI, where I plan to save the namespace node in some per-device thing, and then call _CRS to get the resources
(I mean managarm doesn't seem to free it at any point?)
nodes exposed to client code are permanent
So, do I need to go through ISA int overrides to get IOAPIC for this?
Yes
@fiery turtle when will uacpi 5.0 likely be released?
Could uacpi_kernel_wait_for_work_completion be replaced with a call to uacpi_kernel_schedule_work where the work item signals a semaphore? Would make the kernel API simpler.
and why not do that in wait_for_work_completion?
it's up to you how you implement workqueues
Because it must also wait for inflight interrupts, but also I don't see much benefit in this
also that would imply adding a new type of work
Yeah
Also a lot of people using uacpi have completely broken or stubbed event api support, so the less thats used the better
everyone knows that the best workqueue is executing the work in place 
Technically if you execute uACPI interrupts in a preemptible context, nothing wrong with that
I spin up a pthread for work queue stuff, and pthread_join it untill there are no more threads
@fiery turtle in uacpi_kernel_install_interrupt_handler, irq is an external interrupt that will go trough the IOAPIC, right?
__ensure(irq == 9);
?
yes. it's almost always gsi 9 though
fwiw
oh
but yeah it goes through ioapic
perfect, thx
(and the isa interrupt stuff in madt too)
Its a legacy isa interrupt number
Thats subject to the same translation as any other legacy interrupt
But yeah you can hardcode it to 9 which it is always
From the @fiery ice acpi dump that tried to map a bogus addres in @calm latch pmos:
OperationRegion (HBUS, PCI_Config, Zero, 0x0100)
Field (HBUS, DWordAcc, NoLock, Preserve)
{
Offset (0x40),
EPEN, 1,
, 11,
EPBR, 20,
Offset (0x48),
MHEN, 1,
, 14,
// 17 bit value, some sort of a base register?
MHBR, 17,
}
Name (MH_B, Zero)
Method (GMHB, 0, Serialized)
{
If ((MH_B == Zero))
{
MH_B = (MHBR << 0x0F)
}
Return (MH_B)
}
OperationRegion (MBAR, SystemMemory, (\_SB.PC00.GMHB () + 0x7100), 0x1000)
Field (MBAR, ByteAcc, NoLock, Preserve)
{
Offset (0x10),
RBAR, 64
}
Method (IOMA, 0, NotSerialized)
{
Return ((^RBAR & 0xFFFFFFFFFFFFFFFE))
}
Method (PIDS, 0, NotSerialized)
{
Return (0x00C10000)
}
// The region that tried to map bogus value
OperationRegion (IOMR, SystemMemory, (IOMA () + PIDS ()), 0x0100)
I've extracted the important parts
so it gets some sort of a 17-bit base address from PCI config space, then shifts it up by 0xF bits. The it offsets it by 0x7100 and reads a 64-bit base address from that, which it ANDs with 0xFFFFFFFFFFFFFFFE
this was the address
@fiery ice i think we need a managarm test here before digging deeper or smth
Also whats funny is that aml has a shit ton of non stripped debug logs
But what's weird is that all other addresses looked fine?
Yeah hard to say why it could be bogus
Maybe my kernel map is broken?
thats why i said we should try managarm or smth before continuing
also make sure the pci map is correct as well
Yeah, it could be broken
But no, it can't be
Wait a sec, I'm not at my PC, but I've printed what was given to me by uACPI directly
well it could be a result of the previous mapping being incorrect
since that value is fetched as 10 indirections
The mapping should be correct though
Was it above 4GB?
Maybe I'm truncating uint64_t somewhere
who knows, we're only seeing a tiny portion of the log
Though flanterm wouldn't work then
Since the framebuffer is at 512GB on my PCs
Also, I've added code to deduce caching types from e820, so in theory that should also be correct
Not that long ago
that probably doesnt matter that much on x86 since MTRRs
Yeah, but like in case they are broken
Another thing that can be tried is the i686 build 
yeah
i checked that the 17-bit load from the exact geometry register layout is performed correct
just compared the result against acpica runner
But my PC doesn't want to turn on, and my laptop doesn't have disk space for that build
via etherwake
But still, how would that address go through AND?
That and only removes the bottom 1 bit
Which you can see is not set in the map request
Why did you refuse to map it btw, what check do you have there
Idr, I think it checks that the address is below 1 << 52
Idr if I get it from cpuid or not
Maybe even 1 << 48
Ah

But this addr is beyong 1 << 52, no?
Yes
SEV etc is a popular thing as of recent
ok, what do i have to do after booting it? and do you have an ISO?
just press the power button
oh it's there, thx
wait, how do i boot this via an usb?
unxz + dd
Hopefully it doesn't crash for other unrelated reasons
This is one of those cases where I wish there was a reference uacpi kernel
let's hope
sudo dd if=image of=/dev/sda
We can try obos if this doesn't work 
lol
How are Haiku and ROS going?
No idea tbh, im not monitoring that closely
this is slow XD
Is this like a usb1 drive lol
I recently bought a Kingston drive in a store without research, and even though it's USB 3 and from a reputable manufacturer, it has very slow write speeds as well
usb2
it is just rufus that is slow af
ok, booting managarm weston
no its probably just your drive lol
i can copy an iso to it very fast
but writing with rufus is slow
lol, managarm is misreading my battery XD
by a lot
it says it has like 1MWh XD
and is charging
while it's def not
What about the pwr BTN tho
it's still booting...
Bruh
it's at PRNG reseeding rn
i pressed the power btn while here and it threw assertion failed
and now it is not doing anything
Ffs I thought that assert was fixed lol
XD
@north holly can you give an obos ISO
the latest iso on their server is from 2025....
Wait wtf
but does that version even have uacpi?
Ofc
it went into instant kernel panic 💀
try
Tbh, I also saw some weirdness with it on my macbook in ahci driver, before I moved it to devicesd
Though it's weird...
I'm also compiling a i686 build
I also added a check to get the proper max phys addr now...
what was the reason
bruh how is there not a single bootable hobby kernel 
Mine is bootable 
Who else had a competent kernel?
(i mean with a power button/shutdown driver)
Ironclad uses uACPI??
should i try this?
You could
Like it's the same image, just with max phys addr from CPUID
My i686 image is still compiling
I mean you can also just replace devicesd with a 32 bit version
oh btw
this is normal-ish given the circumstances 
@calm latch can u enable debug logs in uacpi
