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

1 messages · Page 16 of 1

gentle peak
#

i started this rewrite ~16h ago

jaunty fox
#

i will implement a magazines layer for keyronex

median crest
#

Same, mine varies a lot

gentle peak
#

also worth noting that this is a single-processor kernel, so spinlocks only have to disable irqs instead of having an extra atomic op. don't know if it'd make a difference but well

torpid root
#

wow 3m even on my cpu

slim panther
fiery turtle
#

are you using the kvm clock?

gentle peak
fiery turtle
#

what are you using?

gentle peak
#

right now i just ignore the invtsc bit (except for printing a simple warning)

slim panther
#

lol 4.7mil on my machine

gentle peak
#

tsc, unconditionally, even if the invtsc bit isn't set

#

hpet for calibration

fiery turtle
#

interesting

vagrant hull
#

are you absolutely positive the timer is fine though lol

north holly
#

@hollow crescent you should try

gentle peak
north holly
#

looking at all these reminds me that obos' performance is dogshit

frank canopy
jaunty fox
#

i can leap up to
[uacpi]: successfully loaded 1 AML blob, 1705 ops in 0ms (avg 2620798/s)
with no spinlocking/ipl adjustment around slab allocatio

gentle peak
fiery turtle
#

ngl it is kinda shady that the fastest os is closed source

#

but i believe you

vagrant hull
#

i doubt they are cheating

slim panther
#

speedrunner caught cheating in uacpi any%

gentle peak
#

i can make it open source if you want lol it's nothing special yet, the only reason i haven't is that i usually like to get a bit further than this before going open

vagrant hull
#

more so there is a chance they are making a mistake

fiery turtle
#

perhaps

#

but sleep looks accurate

jaunty fox
#

i think muonkous is in the right

#

though i would see how it would look if it were SMP-safe

fiery turtle
#

true

gentle peak
#

i do wonder how much that'd change things

vagrant hull
torpid root
#

add uacpi there meme

gentle peak
#

it should be mostly SMP-safe already, i'd just need to add spinlocks to some areas that right now only use irq guards (off the top of my head: printk, uacpi deferred work, scheduler, idt, mutex slow path, semaphore, timer events)

vagrant hull
#

alright ty

gentle peak
#

oh and ioapic state is also only locked by an irq guard

#

but other than that everything should work fine

#

although the scheduler is obviously Not Optimal for an SMP kernel given that it's a global queue

fiery turtle
#

namespace load any%

#

w/ stubs

jaunty fox
#

the hard limit i can get to at the moment by simple optimisations is 2.6mil (monkuous gets 3.6mil on my system)

fiery turtle
#

literal beast

vagrant hull
#

i mean it's probably gonna be less than 2.5mil so don't bother actually

jaunty fox
#

what i think i can identify in the meantime is that the current limiting factors for me are probably:

  1. IPL management
  2. slab allocator
torpid root
#

fadanoid could you test this please? #1217009725711847465 message

jaunty fox
#

one paradox, i'm faster with freeing enabled than with no-op freeing!

fiery turtle
kindred beacon
#

function segments for LTO?

north holly
#

or smth

fiery turtle
#

ah

kindred beacon
jaunty fox
#

then a trip to the page allocator is avoided

fiery turtle
#

I see

slim panther
#

i'm getting 0% benefit by noping free

jaunty fox
#

that's my hypothesis anyway

kindred beacon
jaunty fox
#

i haven't tested it

#

other possibiltiies are odd changes to code generation

#

different cache characteristics and such

#

it's a promising observation anyway

#

because it means that i am likely to get huge gains from introducing a magazine layer to the slab allocator

#

the operations that can be served from the CPU layer can be coded such to avoid the IPL management overhead by simply disabling interrupts instead

loud ice
torpid root
gentle peak
#

mostly just because i got into a habit of doing so

gentle peak
#

turns out i did everything except for actually making the repo public, fixed now

fiery turtle
#

wow ok

#

very clean implementation

#

do u do this stuff for a living?

gentle peak
#

nah, just a hobby

fiery turtle
#

but you're still an SE right?

gentle peak
#

i'm only 18 lol i'm not anything

fiery turtle
#

damn

#

not even a phd

slim panther
#

i should rethink my allocator approach

#

my slab is very slow

fiery turtle
#

do you want to be mentioned now that its open source?

gentle peak
#

sure

slim panther
#

took the top spot

fiery turtle
#

congrats, very talented work

fiery turtle
gentle peak
#

less talent and more "has had a chronic case of way-too-eager-to-rewrite-stuff for years and now knows good approaches for a lot of stuff"

fiery turtle
#

nice

slim panther
#

extremely relatable

#

(minus the now knows good)

vagrant hull
#

ok so, you have mutexes? what do they do?

gentle peak
fiery turtle
#

very nice

vagrant hull
#

so yeah i do about 4 million now

fiery turtle
#

wait what

#

what did u do

vagrant hull
#

i enfattened my slab

fiery turtle
#

what does that mean

vagrant hull
#

made slabs larger, allowed for larger allocations through slabs, but mainly made slabs larger

fiery turtle
#

thats it?

vagrant hull
#

yup

fiery turtle
#

nice

#

im not sure if I should include it because your mutexes are a no-op right

gentle peak
# vagrant hull ok so, you have mutexes? what do they do?

lock: spin for 40 iters (cmpxchg MUTEX_UNLOCKED->MUTEX_LOCKED_NOQUEUE), disable irqs, check state again to see if it was just unlocked, set state to MUTEX_LOCKED_QUEUED, puts the task on the list of waiting tasks, stops the task
unlock: cmpxchg MUTEX_LOCKED_NOQUEUE->MUTEX_UNLOCKED, if successful early exit, disables irqs, pops the first waiting task off the list, sets state to MUTEX_LOCKED_NOQUEUE if the queue is now empty, starts the task

fiery turtle
#

so u avoid work that other implementations do

vagrant hull
gentle peak
#

the fast path for mutex lock/unlock is a few nanoseconds i believe

vagrant hull
#

my mutexes are no-ops, but i don't foresee them being such a major issue

#

in terms of knocking down the score i mean

fiery turtle
#

probably, should just be a few atomic ops if not contended technically

vagrant hull
#

yeah

fiery turtle
#

linux compat or just posix layer or

gentle peak
#

posix compatibility (well, mostly - the goal is to implement enough that doing the rest in userspace has 0 performance penalty)

fiery turtle
#

any goals for ports?

gentle peak
#

for the os as a whole, NIH all the way to desktop, but that's a very far out goal that will likely never happen (i'm way too eager to rewrite things)

#

ports not sure, maybe java to run a minecraft server or something, and doom ofc

#

oh and i'd like to be able to do the whole self-hosting thing but that's honestly the easiest of those goals

fiery turtle
#

does that mean we'll see your own ACPI subsystem meme

jaunty fox
#

1.1mil or so

#

[00:00:00.011864] [info] uacpi: successfully loaded 1 AML blob, 1705 ops in 1ms (avg 1125196/s)

gentle peak
fiery turtle
#

makes sense

slim panther
#

okay i've done the same and made my slabs larger

#

now i get 1.5m on avg

jaunty fox
#

the big future gains for me will be whenever i add a magazines frontend to the slab allocator

#

that's something i'd want primarily for SMP to decontend the allocator, but it should help here too

median crest
#

honestly I probably need to revisit my mutexes and actually make a proper implementation

#

this is replacing it with a spinlock_acqurie and spinlock_release

fiery turtle
#

Please take a look before I merge

#

Did i get everyone

north holly
fiery turtle
#

get qwinci to run your stuff

north holly
#

when I finally optimize obos I can make a pr to change that value, right

fiery turtle
#

yeah ofc

north holly
fiery turtle
#

i will add changes in batches most likely

#

as new submissions if any come in

north holly
#

I am waiting for the submission to put obos in the 3rd last position meme

#

but seriously I gotta optimize that

fiery turtle
#

lol

#

just wait for tons of submissions and it will look like you're at the top

north holly
#

eggsactly

#

or at the bottom

gentle peak
north holly
#

you're on master right?

gentle peak
#

yeah

north holly
#

clear cache and switch to userspace-work

#

master is months old

gentle peak
#

ah

fiery turtle
#

yeah btw your cmake is bogus, idk why you're calling that command

#

its a uacpi-internal cmake function to add sources lol

north holly
#

wait it is

#

I have had that for months lol

fiery turtle
#

lmao

gentle peak
north holly
#

wut the hell

fiery turtle
#

can't u just send over an iso?

north holly
#

I can

gentle peak
#

that'd work yeah

fiery turtle
#

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

north holly
#

wait infy

fiery turtle
#

did u checkout a wip-pr?

north holly
#

wtf

fiery turtle
#

lol

north holly
#

I indeed did

#

was testing something out for you

fiery turtle
#

b8a2a35fb60719641adefbdb945006cb673c

#

this hash is latest

north holly
#

wha

#

I don't see it on the repo

fiery turtle
#

wait no lmao

#

1721b8a2a35fb60719641adefbdb945006cb673c

north holly
#

yeah

fiery turtle
#

alright i merged the leaderboard for now, will update as people optimize their stuff further

north holly
#

damn it infy

#

as soon as I change obos to use master's commit

#

and am about to commit the change

#

you do that

fiery turtle
#

That shouldn't change your numbers lol

north holly
#

ik

#

it's just a minor inconvinence

#

@gentle peak I fixed it

#

git pull && rm dependencies/needs_download.cmake

gentle peak
#

one second, gotta install docker so that i don't clog up my path with x86_64-elf-*

north holly
#

you do you

fiery turtle
#

Just send over the damn ISO lol

north holly
#

@gentle peak here iso

gentle peak
#

alright ty

fiery turtle
#

Inb4 5 mil

north holly
#

yes 100%

gentle peak
#

38761/s

north holly
#

woo

#

try this one

#

it uses a bump allocator

gentle peak
#

465911/s

fiery turtle
#

Not bad

north holly
#

otherwise it would be the same old

#

obos

fiery turtle
#

Take some inspiration from monkuous

#

If you know what I mean meme

north holly
#

mv proxima.iso obos.iso

#

soon, I will port mimalloc to obos

fiery turtle
#

Find every string that says proxima and replace with obos

north holly
gentle peak
#

i'm pretty sure the kernel image actually doesn't have the string 'proxima' at all

#

since the kernel itself is called hydrogen

fiery turtle
#

Fuck

north holly
#

I feel like that could be made faster

median crest
gentle peak
#

explosion

north holly
#

memory mapping is bottlenecked by the allocator, and the allocator is probably bottlenecked by the memory mapping

gentle peak
#

or well

fiery turtle
#

Uranium kernel when

gentle peak
#

not explosion on our scale

fiery turtle
#

I have an idea

gentle peak
#

release of a significant amount of energy relative to the energy of the resulting helium nucleus

#

how about that

north holly
#

if nyaux ever surpasses me in perf
I will rewrite obos /j

fiery turtle
#

Bump the number for every rewrite

#

What comes after hydrogen

gentle peak
fiery turtle
#

Now thats a based kernel name

median crest
#

my biggest trouble is my slow ass mutex

north holly
median crest
#

which is why I am looking into getting a real lock

north holly
#

I have 7x more code than comments

median crest
#

cant believe I'm trying this hard to optimise for a fucking fake number on a table

#

probably not that different from my corporate job

north holly
fiery turtle
#

Still the only hobby os that can build gcc

north holly
#

when will astral run minecraft servers

#

or even better

#

minecraft

gentle peak
median crest
fiery turtle
#

Good idea

median crest
#

my og stress test was neofetch, then running configure

fiery turtle
#

Lol

north holly
fiery turtle
#

Neofetch stress test

north holly
#

what does it do that's so stressful

fiery turtle
#

Exists

median crest
north holly
#

trust, obos definitely won't die when you blow on it as soon as I get userspace

median crest
#

now its stable but slow

#

which I will fix

north holly
#

(+2 processes has not been tested ever)

#

((in obos))

median crest
#

(my manhood has been challenged

north holly
fiery turtle
north holly
fiery turtle
north holly
#

good idea

jaunty fox
#

who's doing the benchmarking now?

north holly
#

monkuous

fiery turtle
#

Monkuous is our leader now

strong heath
fiery turtle
strong heath
#

it configures fine itself, I can configure ironclad inside ironclad

fiery turtle
#

Oh nice

#

Then you might be able to as well

#

But your os is not hobby

#

You get paid for it

median crest
#

you should do it I wanna see the funny seal do things

strong heath
#

is this what it feels to be denied hobbyhood

fiery turtle
#

Yup

strong heath
#

I feel empty

fiery turtle
#

Youre a corporation now

north holly
#

considering it uses ada

median crest
#

@strong heath hire me I will accept very low pay and write ada

north holly
#

should be pretty safe

strong heath
#

I wish a foundating didnt need 30k starting capital to be funded, else I might have had an ironclad fundation

median crest
#

just ahve to learn it fist

vagrant hull
#

hiring mathew is a good idea

#

i vouch for it

fiery turtle
#

True

strong heath
#

I cannot hire anyone without a legal organization

fiery turtle
#

Hire nyaux as well

north holly
vagrant hull
strong heath
#

fair enough

fiery turtle
north holly
#

somehow nyaux managed to make something less stable than obos

jaunty fox
#

one underrated development of tonight

#

cynix is publicised now

median crest
#

true

north holly
fiery turtle
#

And hydrogen

north holly
#

((I should remove it from existance, it was terrible))

fiery turtle
#

It was gonna be closed source

jaunty fox
strong heath
#

imagine calling an OS after the lightest element

fiery turtle
strong heath
#

if you are gonna name an OS, name it after lead

jaunty fox
#

floats like a butterfly, stings like a bee

fiery turtle
#

^

north holly
#

I should name my os after alexander fleming

fiery turtle
#

Aml is scared of this os

jaunty fox
north holly
#

yes

median crest
#

I named astral that because space is fucking cool

#

you cannot argue with this logic

north holly
#

I named obos because well

fiery turtle
#

I like astrals theme

jaunty fox
#

it's incredible btw how we invented almost everything

#

scots on top non stop

fiery turtle
north holly
#

best human invention: cheese

fiery turtle
north holly
#

yeah

#

creative name

median crest
#

but yeah, I know how I can (probably) improve astral's ops/sec by 20%-50%

fiery turtle
#

I know obos lore

median crest
#

now into the grind

fiery turtle
north holly
# fiery turtle I know obos lore

the stone age of obos: first and second rewrite
iron age: third rewrite
middle ages: fourth rewrite
modern time: current rewrite
future: next rewrite??

fiery turtle
#

Pls no

north holly
#

jk

#

crazy how this obos rewrite started -1 days ago

#

(/j)

#

-1 days ago means
in one day thonk

median crest
#

in 3 rewrites you will do it in astral because it will already be the year of the astral desktop

gentle peak
#

2029 will be the year of the obos desktop

north holly
#

yes.

#

my christmas break starts next week

#

so I can rather go outside

#

or smth

#

or work on obos

median crest
hollow crescent
vast kestrel
flat badge
#

the latency of rep movsb is still pretty high (at least on some CPUs), so you should only do that for large regions

torpid root
dusky glade
calm latch
#

pmOS desktop

#

(maybe I'll finally have a working shell)

#

and with no rewrites

kindred beacon
#

2024 was the year of getting managarm desktop somewhat daily drivable

#

2025 will be the year of the managarm desktop

#

1000000000 % confirmed

fiery turtle
#

should i pin this

torpid root
#

kmanagarm with plasma 6 in 2025

median crest
#

Managarm will replace windows

fiery turtle
#
/*
 * Safely mask the event before we modify its handlers.
 *
 * This makes sure we can't get an IRQ in the middle of modifying this
 * event's structures.
 */
static uacpi_bool gpe_mask_safe(struct gp_event *event)
{
    uacpi_u8 this_mask;
    uacpi_bool was_masked;

    this_mask = gpe_get_mask(event);

    // No need to flush or do anything if it's not currently enabled
    if (!(event->reg->current_mask & this_mask))
        return UACPI_FALSE;

    if (gpe_masked(event)) {
        /*
         * This GPE is masked, but there still might be pending work involving
         * its handlers. Wait in case it was masked very recently.
         */
        uacpi_kernel_wait_for_work_completion();
        return UACPI_FALSE;
    }

    // 1. Mask the GPE, this makes sure its state is no longer modifyable
    gpe_mask_unmask(event, UACPI_TRUE);

    /*
     * 2. Wait for in-flight work & IRQs to finish, these might already
     *    be past the respective "if (masked)" check and therefore may
     *    try to re-enable a masked GPE.
     */
    uacpi_kernel_wait_for_work_completion();

    /*
     * 3. Now that this GPE's state is unmodifyable and we know that currently
     *    in-flight IRQs will see the masked state, we can safely disable this
     *    event knowing it won't be re-enabled by a racing IRQ.
     */
    set_gpe_state(event, GPE_STATE_DISABLED);

    /*
     * 4. Wait for the last possible IRQ to finish, now that this event is
     *    disabled.
     */
    uacpi_kernel_wait_for_work_completion();

    return UACPI_TRUE;
}

Mental gymnastics to make GPE modification thread-safe

#
/*
 * Waits for two types of work to finish:
 * 1. All in-flight interrupts installed via uacpi_kernel_install_interrupt_handler
 * 2. All work scheduled via uacpi_kernel_schedule_work
 *
 * Note that the waits must be done in this order specifically.
 */
uacpi_status uacpi_kernel_wait_for_work_completion(void);

And this is what is now expected from wait_for_work_completion

#

linux already does this for acpica as well:

void acpi_os_wait_events_complete(void)
{
    /*
     * Make sure the GPE handler or the fixed event handler is not used
     * on another CPU after removal.
     */
    if (acpi_sci_irq_valid())
        synchronize_hardirq(acpi_sci_irq);
    flush_workqueue(kacpid_wq);
    flush_workqueue(kacpi_notify_wq);
}
#

although it doesnt bother masking it because they dont care i guess

north holly
hollow crescent
north holly
#

Wait you don't have kt

#

*it

#

Nvm then

north holly
#

Using a new log added to uacpi

north holly
hollow crescent
#

They don't, I just have a set of priorities

#

First, finish the userspace memory manager, then start userspace

#

Then worry about other things like uACPI

#

Although a lot of things that are requisites of user space, are also not done

fiery turtle
#

if u only want table parsing then uacpi doesnt need anything besides map/unmap

#

so technically doesnt matter

hollow crescent
#

practically there are bigger fish to fry

#

the fact I'm not frying any of them is part 2

fiery turtle
#

i will integrate it first thing so that i dont have to duplicate table parsing for stuff like hpet or madt

rustic compass
#

does the benchmark requires uacpi to run in kernelspace or can it run in userspace?

fiery turtle
#

i mean you're putting yourself at a disadvantage

#

and pmos already runs it in userspace

#

so no doesnt matter at all

torpid root
#

wow I also get less points with no free()

wind fiber
torpid root
#

I was 70% serious tbh

calm latch
#

Managram in mainline clang when

slim panther
#

it's a WIP pr

#

cc @kindred beacon meme

#

i think we just have to ping maintainers again

calm latch
#

What do you do without swap though

flat badge
#

Hm?

slim panther
#

wat

fiery turtle
#

Alright the final uACPI thread safety (part 3) PR is basically done, waiting for CI and merging

slim panther
fiery turtle
#

This means that uACPI is basically ready for 1.0, although I still wanted to add support for exotic opregions before declaring it

slim panther
#

release 1.0 and then immediately api break with uapi ultrameme

fiery turtle
#

lol

#

if anything uapi will be an optional layer

fiery turtle
#

Merged & issue closed

#

I will push to implement support for exotic opregions in the coming days and release uACPI 1.0

#

that shouldnt be too hard I think

#

that should put me mostly at feature parity with acpica

hollow elm
#

what opregions do you want to support?

loud ice
#

im guessing all of them

fiery turtle
#
UACPI_ADDRESS_SPACE_SMBUS = 4,
UACPI_ADDRESS_SPACE_IPMI = 7,
UACPI_ADDRESS_SPACE_GENERAL_PURPOSE_IO = 8,
UACPI_ADDRESS_SPACE_GENERIC_SERIAL_BUS = 9,
UACPI_ADDRESS_SPACE_PCC = 0x0A,
UACPI_ADDRESS_SPACE_PRM = 0x0B,
UACPI_ADDRESS_SPACE_FFIXEDHW = 0x7F,
#

all of these require special handling

hollow elm
#

i assume they also require special os support?

fiery turtle
#

yeah, via uacpi_install_address_space_handler

#

no hobby os with such drivers yet

#

but still important to get these done

#

linux does support all of them

fiery turtle
north holly
#

What's generic serial? Com ports?

fiery turtle
#

you wish

#

special controllers i think

north holly
#

Sounds boring and painful

#

Which is why obos will be the first to have them

fiery turtle
#

I would tell u which driver linux uses for it but

#

bootlin decides to die

fiery turtle
#
status = acpi_install_address_space_handler(adev->handle,
                                            ACPI_ADR_SPACE_GSBUS,
                                            &mshw0011_space_handler,
                                            NULL,
                                            data);
if (ACPI_FAILURE(status)) {
        dev_err(&client->dev, "Error installing i2c space handler\n");
        acpi_bus_detach_private_data(adev->handle);
        kfree(data);
        return -ENOMEM;
}
#

yeah thats the only user in the entire kernel

fiery turtle
# fiery turtle
OperationRegion (OR01, GenericSerialBus, Zero, 0x0100)
Field (OR01, BufferAcc, NoLock, Preserve)
{
    Connection (I2Z0), 
    AccessAs (BufferAcc, AttribRawProcessBytes (0x02)), 
    SAN0,   8
}
fiery turtle
#
    /*
     * _REG methods for global address space handlers (installed to root)
     * get called during the namespace initialization, no reason
     * to call them here manually as that will be done later by init code
     * anyway. Just delay that work until later.
     */
    if (device_node == uacpi_namespace_root() &&
        g_uacpi_rt_ctx.init_level == UACPI_INIT_LEVEL_NAMESPACE_LOADED)
        goto out;

Least dumb uACPI code

#

I think this breaks early EC registration

#

in theory

fiery turtle
#

i wonder if i should get rid of uacpi_kernel_raw_* helpers

#

and just map io/mem manually

#

the idea there was that the kernel can keep a cache like linux

#

but i think its just annoying to have 9999 extra helpers

#

to implement in the kernel

#

so like uacpi_gas_read currently does this:

if (gas->address_space_id == UACPI_ADDRESS_SPACE_SYSTEM_IO) {
    ret = uacpi_kernel_raw_io_read(
        address, access_byte_width, &data
    );
} else {
    ret = uacpi_kernel_raw_memory_read(
        address, access_byte_width, &data
    );
}
#

if i get rid of raw stuff it will call map, read, unmap

#

there's already a precedent for this anyway since i handle SystemMemory opregions myself and not via kernel raw_read/write

calm latch
#

You can make it optional (?)

fiery turtle
#

#polls message

#

lets see

fiery turtle
slim panther
#

less shit to implement = better

fiery turtle
#

if these are removed uacpi will instead do map(), io_read/write, unmap() and for memory it will do the IO itself completely

#

I initially stole the raw* helpers idea from ACPICA but now i think it just sucks

#

ok looks like people hate the raw api anyway lmao

#

but ill wait for the vote to finish

hollow elm
#

this makes me wonder, what caching requirements do opregions have

#

it can either be mmio or just ram (e.g. nvs)

#

and on arm etc it matters since there arent mtrrs to set it for you

gentle peak
#

i believe the intended way to determine caching mode is to check the memory map, but on x86 at least it's fine to rely on mtrrs

fiery turtle
#

^

hollow elm
#

how does it help? acpi reclaimable & nvs => normal ram, reserved,not in mmap => device memory?

gentle peak
#

yeah basically

hollow elm
#

feels a bit iffy since reserved does not imply !ram (to me at least)

#

but if thats the intended way then so be it

gentle peak
#

there aren't really better options, i don't think aml specifies the caching mode so it's not like uacpi can tell you how to map it

fiery turtle
#

yup

#

thats how linux does it at least

flat badge
#

map + write + unmap is slow af

#

It's probably two orders of magnitude slower than a raw write

#

Especially for proper SMP OSes that implement TLB shootdown

fiery turtle
#

but a raw write is also done on a physical address

#

so u kinda have to map it no?

flat badge
#

unmap requires an IPI to all CPUs and blocking for the other cpus to react

#

No, a raw write can use a direct mapping

mortal yoke
#

you can use direct mapping with the map fn too

flat badge
#

If you get rid of the helpers, you could keep the cache in uacpi such that you only ever map once

flat badge
mortal yoke
#

well not on all platforms but with like x86_64 or whatever

flat badge
#

A direct mapping for raw writes must be contiguous at the granularity of the largest possible write

#

which is 8 in practice

#

Mapping via direct map must be contiguous at an arbitrary granularity

flat badge
jaunty fox
#

not one bit

#

but since linux is doing it i assume it's the only way

flat badge
#

And on rv the memory controller is supposed to handle cacheability transparently

fiery turtle
#

kernel_map will be called with the size of the write

#

so i dont see any difference in this case

flat badge
#

I guess you could distinguish between single page and multi page mappings, that's true

#

Then it's not that bad

rustic compass
mortal yoke
#

it can't really know whether it needs it in the future

#

what it does rn afaik for eg. op regions is mapping it once

rustic compass
#

good enough

left orbit
#

did i see right that you were building linux with uacpi yesterday? or am i tripping

#

i saw some messages with linker error that referenced uacpi and vmlinuz.o meme

#

i was wondering how that went/how it's going

fiery turtle
#

i was yeah

#

i got too lazy to implement kernel api lamo

#

i might finish it later

fiery turtle
frank canopy
#

in case im misunderstanding, is there any realistic thing for the map/unmap io functions to do on x86? id assumed they were mostly there for mmio on other architectures etc

fiery turtle
frank canopy
#

ahhh ok

fiery turtle
#
@@ -564,13 +581,30 @@ uacpi_status uacpi_gas_write(const struct acpi_gas *gas, uacpi_u64 in_value)
             uacpi_u64 address = gas->address + (index * access_byte_width);

             if (gas->address_space_id == UACPI_ADDRESS_SPACE_SYSTEM_IO) {
-                ret = uacpi_kernel_raw_io_write(
-                    address, access_byte_width, data
-                );
+                uacpi_handle handle;
+
+                ret = uacpi_kernel_io_map(address, access_byte_width, &handle);
+                if (uacpi_unlikely_error(ret))
+                    return ret;
+
+                ret = uacpi_kernel_io_write(handle, 0, access_byte_width, data);
+                uacpi_kernel_io_unmap(handle);
             } else {
-                ret = uacpi_kernel_raw_memory_write(
-                    address, access_byte_width, data
-                );
+                void *virt;
+
+                virt = uacpi_kernel_map(address, access_byte_width);
+                if (uacpi_unlikely(virt == UACPI_NULL))
+                    return UACPI_STATUS_MAPPING_FAILED;
+
+                ret = uacpi_system_memory_write(virt, access_byte_width, data);
+                uacpi_kernel_unmap(virt, access_bit_width);
             }
#

Now that raw helpers are gone, uacpi_gas_write is going to look like this

#

kinda bulky but at least its less stuff for kernel to implement

fiery turtle
#

actually I just made an abstraction around io r/w

uacpi_status uacpi_system_io_read(
    uacpi_io_addr address, uacpi_u8 width, uacpi_u64 *out
);
uacpi_status uacpi_system_io_write(
    uacpi_io_addr address, uacpi_u8 width, uacpi_u64 in
);

Maybe I could implement a transparent LRU cache around it if the need arises

#

(this is internal api)

#

that's 4 less kernel_api functions to implement

#

I think that's pretty good

dusky glade
#

hold on i think nyaux can do faster now

kindred beacon
#

Ah ok I see

#

Windows skill issue

dusky glade
torpid root
#

switch to mamogram

sterile egret
calm latch
slim panther
#

made some small opts and i'm now on 1.5 mil in the benchmark

fiery turtle
#

Nice, but did you fix the stack corruption

slim panther
#

no 😢

#

i have genuinely no clue what it could be

#

see the latest messages

fiery turtle
#

Yeah idk, id printf the shit out of it

slim panther
#

#1287456798407790684 message

#

maybe i can clear the TSS?

#

not sure if that does anything

fiery turtle
#

Doubt it

#

Only stack pointer is used from it

#

I bet it's a one line fix

slim panther
#

probably

#

nobody can help me though nooo

fiery turtle
#

The Gnu debugger of course

slim panther
#

it can't

#

this is kvm only

fiery turtle
#

Kvm is debuggable under gdb tho

slim panther
#

didnt work when i tried

#

it just fell through my breakpoints

fiery turtle
#

I think it should

#

Not sure

hollow elm
slim panther
#

i keep forgetting

slim panther
fiery turtle
north holly
slim panther
#

^

fiery turtle
#

there should be something like -accel tcg,fortify=on or something

#

thats slow but actually checks stuff

slim panther
#

qemu-system-x86_64: -accel tcg,fortify=on: Property 'tcg-accel.fortify' not found

fiery turtle
#

should be => I want that feature

slim panther
#

oh

#

i thought you meant "i'm not certain but there must be a feature like that"

fiery turtle
#

i worder that poorly

sterile egret
slim panther
#

@fiery turtle 😢

north holly
#

no -Werror for uacpi

#

is what I do

slim panther
#

is this another gcc false alarm

#

fucking gnu tools

#

trash

north holly
#

yes

fiery turtle
#

it is yeah

#

ill try to fix it, but i have an old gcc lol

slim panther
#

woe

#

i'm on latest latest

fiery turtle
#

i have whatever ubuntu 20 ships with

slim panther
#

damn

#

build from source galaxybrain

#

oh damn why does -smp tank so much performance on the uacpi bench

#

woe

#

okay new record is 1.5mil

#

it's bottlenecked by the not fair scheduler and slab of shit

fiery turtle
slim panther
#

i did already

fiery turtle
#

hm?

slim panther
#

i need to find it

#

i posted it days ago

fiery turtle
#

oh u did?

#

i guess i missed it somehow

slim panther
#

.

fiery turtle
#

thx

#

I literally have a comment right above it lmao

#

this is literally what gcc is complaning about

#

oh well

slim panther
#

welp

fiery turtle
#

nice, its forcing me to zero a 64-byte struct

slim panther
#

= {0} meme

fiery turtle
#

i know

#

but its still not free

slim panther
#

true

#

muh safety

kind mantle
#

I think there was an attribute for this?

fiery turtle
#

ill think of a solution

kind mantle
#

The other option is to init to 0 on error just to shut GCC up, while not impacting performance too much because it's unlikely to happen.

fiery turtle
#

There's already a return on error above it in the switch, but apparently thats not enough

slim panther
#

@fiery turtle is it normal to get a shit ton of warnings on real hw?

#

something about a scope not found

fiery turtle
#

Do you implement all kernel api?

slim panther
#

no

fiery turtle
#

Then yes

#

Try pmos and see if it produces any warnings like what u saw

vast kestrel
#

How does windows treat the scope not found and alike?

fiery turtle
#

I think skips as well but id have to double check

fiery turtle
#

I might have to pre-map all IO registers from FADT

#

otherwise i leak a mapping if it shuts down or suspends too fast

#

which is probably a good idea anyway

vast kestrel
#

Lmao

fiery turtle
#

or option 2

#

remove io mapping abstractions entirely

#

because so far everyone just stubs them out anyway

#

since im doing kernel_api simplifications anyway..

#

ill make a poll

vast kestrel
#

I mean, the io port abstraction is only relevant for non-x86

#

And micro kernels

fiery turtle
#

#polls message

fiery turtle
vast kestrel
#

Even if stubbed I think it's still the correct and most versatile abstraction

fiery turtle
#

thing is

vast kestrel
#

Could also make it optional

fiery turtle
#

u can still keep a cache internally and map if needed, like for the raw helper before

vast kestrel
#

Like you have for the printf

#

Yeah but you don't know when to unmap

fiery turtle
#

thing is this abstraction adds a ton of extra complexity

vast kestrel
#

Even tho for io it probably doesn't matter

fiery turtle
#

i cant make it optional and not leak at the same time for example

#

or I can but its not trivial

#

idk

vast kestrel
#

Tbh

#

Because of how acpi is

#

It's probably fine to keep the mapping forever

#

Even tho 32bit might not like it

fiery turtle
#

probably

#

32-bit arm u mean?

vast kestrel
#

32bit address space

#

You have limited space for mapping

fiery turtle
#

io is port-io

#

SystemIO not SystemMemory

#

or do u mean in general

vast kestrel
#

Ooooo

#

Yeah for port io it probably doesn't matter

#

Or well, like you said 32bit arm

#

Hmmmm

fiery turtle
#

then again i think SystemIO is used only on x86 even though technically they could use it for arm

vast kestrel
#

Yeah for io I think lazy mapping for whoever needs it is enough

#

And for the once in a blue moon it happens on arm they can handle it

fiery turtle
#

inb/outb etc

vast kestrel
#

SystemMemory includes MMIO

fiery turtle
#

^

vast kestrel
#

SystemIO is purely io ports

#

On arm/riscv they will be memory mapped too because no instructions

fiery turtle
#

ACPICA has a check for SystemIO like > 0xFFFF die() or something

#

so its probably not used for arm

vast kestrel
#

Other than very legacy devices it's not really needed

fiery turtle
#

yeah

vast kestrel
#

Like, sure alot of devices have port io for simpler reg access, but no one actually is going to access them like that since you have a full address space anyways

#

It's mostly meant for legacy bioses running real mode and don't want unreal mode

fiery turtle
#

true

#
acpi_status acpi_os_read_port(acpi_io_address port, u32 *value, u32 width)
{
    u32 dummy;

    if (!IS_ENABLED(CONFIG_HAS_IOPORT)) {
        /*
         * set all-1 result as if reading from non-existing
         * I/O port
         */
        *value = GENMASK(width, 0);
        return AE_NOT_IMPLEMENTED;
    }

    if (value)
        *value = 0;
    else
        value = &dummy;

    if (width <= 8) {
        *value = inb(port);
    } else if (width <= 16) {
        *value = inw(port);
    } else if (width <= 32) {
        *value = inl(port);
    } else {
        pr_debug("%s: Access width %d not supported\n", __func__, width);
        return AE_BAD_PARAMETER;
    }

    return AE_OK;
}
torpid root
#

<= there is weird

fiery turtle
#

acpica passes misaligned bit count unlike uacpi

#

uacpi aligns up to byte count to make it less confusing

#

but whats funny is aarch64 selects CONFIG_HAS_IOPORT LULW

gentle peak
#

imo the pio map/unmap should stay, they're helpful for microkernels that use iopb and for monolithic ones and microkernels that use iopl you can just cast the base address to a pointer and back

vast kestrel
#

Yeah but you can also iopb on demand

fiery turtle
#

we have pmos as an example and it just toggles the IOPL bit LULW

fiery turtle
#

or if you're lazy u can map() do_io() unmap()

vast kestrel
#

Tbf, given you are going to give all ports to acpi anyways

#

Why not iopl

gentle peak
#

that's true

fiery turtle
#

true actually

vast kestrel
#

Or premap everything you allow and catch the fault

#

/verify with whitelist

fiery turtle
#

yeah thats actually a smart thought

#

because the firmware might write to any io port

#

u dont know which one does what

vast kestrel
#

Like, Linux only has a tiny blacklist iirc

fiery turtle
#

yeah i think cmos is masked

#

and something else

vast kestrel
#

CMOS, PCI and some others

fiery turtle
#

the blacklist is actually built into acpica

vast kestrel
#

oh

fiery turtle
#

and I think windows also has a blacklist for ports

vast kestrel
#

Does windows have a blacklist?

fiery turtle
#

ill have to implement that in uacpi as well probably

fiery turtle
#
/*
 * Protected I/O ports. Some ports are always illegal, and some are
 * conditionally illegal. This table must remain ordered by port address.
 *
 * The table is used to implement the Microsoft port access rules that
 * first appeared in Windows XP. Some ports are always illegal, and some
 * ports are only illegal if the BIOS calls _OSI with nothing newer than
 * the specific _OSI strings.
 *
 * This provides ACPICA with the desired port protections and
 * Microsoft compatibility.
 *
 * Description of port entries:
 *  DMA:   DMA controller
 *  PIC0:  Programmable Interrupt Controller (8259A)
 *  PIT1:  System Timer 1
 *  PIT2:  System Timer 2 failsafe
 *  RTC:   Real-time clock
 *  CMOS:  Extended CMOS
 *  DMA1:  DMA 1 page registers
 *  DMA1L: DMA 1 Ch 0 low page
 *  DMA2:  DMA 2 page registers
 *  DMA2L: DMA 2 low page refresh
 *  ARBC:  Arbitration control
 *  SETUP: Reserved system board setup
 *  POS:   POS channel select
 *  PIC1:  Cascaded PIC
 *  IDMA:  ISA DMA
 *  ELCR:  PIC edge/level registers
 *  PCI:   PCI configuration space
 */
static const ACPI_PORT_INFO     AcpiProtectedPorts[] =
{
    {"DMA",     0x0000, 0x000F, ACPI_OSI_WIN_XP},
    {"PIC0",    0x0020, 0x0021, ACPI_ALWAYS_ILLEGAL},
    {"PIT1",    0x0040, 0x0043, ACPI_OSI_WIN_XP},
    {"PIT2",    0x0048, 0x004B, ACPI_OSI_WIN_XP},
    {"RTC",     0x0070, 0x0071, ACPI_OSI_WIN_XP},
    {"CMOS",    0x0074, 0x0076, ACPI_OSI_WIN_XP},
    {"DMA1",    0x0081, 0x0083, ACPI_OSI_WIN_XP},
    {"DMA1L",   0x0087, 0x0087, ACPI_OSI_WIN_XP},
    {"DMA2",    0x0089, 0x008B, ACPI_OSI_WIN_XP},
    {"DMA2L",   0x008F, 0x008F, ACPI_OSI_WIN_XP},
    {"ARBC",    0x0090, 0x0091, ACPI_OSI_WIN_XP},
    {"SETUP",   0x0093, 0x0094, ACPI_OSI_WIN_XP},
    {"POS",     0x0096, 0x0097, ACPI_OSI_WIN_XP},
    {"PIC1",    0x00A0, 0x00A1, ACPI_ALWAYS_ILLEGAL},
    {"IDMA",    0x00C0, 0x00DF, ACPI_OSI_WIN_XP},
    {"ELCR",    0x04D0, 0x04D1, ACPI_ALWAYS_ILLEGAL},
    {"PCI",     0x0CF8, 0x0CFF, ACPI_OSI_WIN_XP}
};
vast kestrel
#

I mean, tbh it's mostly superficial and to discourage bugs

fiery turtle
#

PCI is technically legal even

vast kestrel
#

Damn

fiery turtle
#

u just have to _OSI("Windows XP")

vast kestrel
#

Lol

fiery turtle
#

thats kinda strange but okay i guess

#

earlier versions of aml might do nasty stuff ig?

vast kestrel
#

I wonder if windows does the same

fiery turtle
#

it says so in the comment above at least

vast kestrel
#

Yeah but is windows doing the same check or is just that winxp didn't check

fiery turtle
#

The table is used to implement the Microsoft port access rules that
first appeared in Windows XP
Ig?

vast kestrel
#

Hmmmm

fiery turtle
#
/* Port illegality may depend on the _OSI calls made by the BIOS */
if (PortInfo->OsiDependency == ACPI_ALWAYS_ILLEGAL ||
    AcpiGbl_OsiData == PortInfo->OsiDependency)
{
    ACPI_DEBUG_PRINT ((ACPI_DB_VALUES,
        "Denied AML access to port 0x%8.8X%8.8X/%X (%s 0x%.4X-0x%.4X)\n",
        ACPI_FORMAT_UINT64 (Address), ByteWidth, PortInfo->Name,
        PortInfo->Start, PortInfo->End));

    return_ACPI_STATUS (AE_AML_ILLEGAL_ADDRESS);
}
#

this check looks bogus as well

#

AcpiGbl_OsiData == PortInfo->OsiDependency since its an ==

#

esentially if latest_requested_win ==

#

so disallowed for XP

#

but allowed for e.g. windows vista?

#

how does this make sense

#

@gentle peak btw did we convince you to vote for option 1 instead?

gentle peak
#

you can change your vote?

fiery turtle
#

think so?

#

"remove vote"

gentle peak
#

anyway yeah I didn't think it through fully, didn't realize you'd need the equivalent of iopl3 even in microkernels

fiery turtle
#

nice

#

actually im not sure how u could even run it in userspace and support suspend for example

#

like it wakes up in real mode

#

then you have to do full hw re-init

#

or i guess u would have to split responsibilities somehow

#

idk

fiery turtle
#

Alright time to implement support for these

    UACPI_ADDRESS_SPACE_SMBUS = 4,
    UACPI_ADDRESS_SPACE_SYSTEM_CMOS = 5,
    UACPI_ADDRESS_SPACE_PCI_BAR_TARGET = 6,
    UACPI_ADDRESS_SPACE_IPMI = 7,
    UACPI_ADDRESS_SPACE_GENERAL_PURPOSE_IO = 8,
    UACPI_ADDRESS_SPACE_GENERIC_SERIAL_BUS = 9,
    UACPI_ADDRESS_SPACE_PCC = 0x0A,
    UACPI_ADDRESS_SPACE_PRM = 0x0B,
    UACPI_ADDRESS_SPACE_FFIXEDHW = 0x7F,
#

i'll start with PCC

#

it should be simple

#

each opregion represents a buffer, writes copy into it, reads copy from it, write at a specific offset invokes the user handler

left orbit
#

what the fuck is a pcc

fiery turtle
#
 * The PCC Address Space also referred as PCC Operation Region pertains to the
 * region of PCC subspace that succeeds the PCC signature. The PCC Operation
 * Region works in conjunction with the PCC Table(Platform Communications
 * Channel Table). PCC subspaces that are marked for use as PCC Operation
 * Regions must not be used as PCC subspaces for the standard ACPI features
 * such as CPPC, RASF, PDTT and MPST. These standard features must always use
 * the PCC Table instead.
 *
 * This driver sets up the PCC Address Space and installs an handler to enable
 * handling of PCC OpRegion in the firmware.

idk

calm latch
#

PCC is PCC what don't you understand

vast kestrel
#

Platform communication channel

#

Tbh it seems like an even more generic EC

calm latch
#

Do a lot of PCs use it?

left orbit
#

judging by the fact it wasn't an immediate priority for uacpi, my guess would be no

calm latch
#

I mean GPIO spec says it's for reduced hardware platforms, and it turned out that new laptops wire power buttons through them

fiery turtle
#

it barely even exists

calm latch
#

Btw, I think the macbook is doing some stuff with AHCI controller when turning off

fiery turtle
#

i mean yeah that makes sense

#

like disabling it?

vast kestrel
#

I recently noticed that if I force shutdown my PC using the power button some of the LEDs stay on, while with normal acpi shutdown they get turned off

calm latch
fiery turtle
#

possible

fiery turtle
#

yes

vast kestrel
#

Fun fact, it used to be that acpi shutdown from windows also left the LEDs on, but after a bios update it was fixed :^)

fiery turtle
#

lol

vast kestrel
#

GPIO doesn't have to be done from the GPIO address space, it might be accessed by acpi using the pch directly

calm latch
vast kestrel
#

that's what I seen a lot of server hardware do at least, accessing random GPIO regs in the pch when doing stuff

fiery turtle
#

thats what they do for SMBus

#

yet they dont do it for EC for whatever reason

#

even though there's an SMBUS address space opregion

#

(technically supported)

calm latch
#

Could they be doing that if there's no driver?

vast kestrel
#

I think it's just that they use the EC driver from one of their drivers while not needing the smbus for one of their drivers

#

Or they just race :^)

fiery turtle
#

some firmware drops into SMM if EC is not available

#

and reads EC via that

calm latch
#

Lol

#

You gotta support Windows XP

vast kestrel
#

Tbh shit like smbus is annoying to have drivers for

#

Cause it's chipset dependent

fiery turtle
#

is it?

vast kestrel
#

I think so, the Intel smbus controlled changed between chipsets

#

Same for the Intel GPIO controller

#

Especially with some of the Intel socs

fiery turtle
#

L

vast kestrel
#

Where they also have GPIO/smbus as a feature for the board

#

Some even have uart dma :^)

fiery turtle
#

bruh

fiery turtle
#
switch (region->space) {
case UACPI_ADDRESS_SPACE_PCC: {
    uacpi_u8 *cursor;

    cursor = region->internal_buffer + offset;

    /*
     * Reads from PCC just return the current contents of the internal
     * buffer.
     */
    if (op == UACPI_REGION_OP_READ) {
        uacpi_memcpy(in_out, cursor, byte_width);
        goto out;
    }

    uacpi_memcpy(cursor, in_out, byte_width);

    // Dispatch a PCC send command if this was a write to the command field
    if (offset >= 12 && offset < 16) {
        uacpi_region_pcc_send_data data = {
            .region_context = region->user_context,
            .handler_context = handler->user_context,
            .buffer = region->internal_buffer,
            .length = region->length,
        };

        op = UACPI_REGION_OP_PCC_SEND;

        uacpi_namespace_write_unlock();
        ret = handler->callback(op, &data);
        uacpi_namespace_write_lock();
    }

    break;
}
default: {
    uacpi_region_rw_data data = {
        .region_context = region->user_context,
        .handler_context = handler->user_context,
        .byte_width = byte_width,
        .offset = offset,
    };

    if (op == UACPI_REGION_OP_WRITE) {
        data.value = *in_out;
        uacpi_trace_region_io(
            region_node, space, op, abs_offset,
            byte_width, *in_out
        );
    }

    uacpi_namespace_write_unlock();
    ret = handler->callback(op, &data);
    uacpi_namespace_write_lock();

    if (uacpi_unlikely_error(ret))
        break;

    if (op == UACPI_REGION_OP_READ) {
        *in_out = data.value;
        uacpi_trace_region_io(
            region_node, space, op, data.offset,
            byte_width, data.value
        );
    }

    break;
}
}

Alright I guess this is the framework of how I will be adding support for other address spaces

fiery turtle
#

causing a larger stack usage

#

which is annoying

vast kestrel
#

Use alloca :^)

#

Tbf alloca could get the same treatment depending on impl

fiery turtle
#

on gcc it probably would

#

since its implemented in IR

vast kestrel
#

Especially if it's constant size and not in a loop

fiery turtle
#

yup

rustic compass
#

Infy your uacpi api isn't liked by the rust chatKEKW
#592856094527848449 message

fiery turtle
#

here we go with the vtable stuff again

#

not biased opinion at all

#

look ill add vtable mode some time in the future

rustic compass
#

The current api is fine I just had some trouble with the rust-rust interface

slim panther
#

you mean it's not liked by one person

rustic compass
#

I would have used the linker for rust-rust too but extern rust isn't exactly stable, apparently even when just using a crate from crates.io

slim panther
#

that's an issue with the rust toolchain though

#

not with uacpi

fiery turtle
#

thats not how the rust mind works LULW

slim panther
#

imo maintaining two apis is unnecessary for basically no added benefit

#

either we only do vtables or only linker

fiery turtle
#

i agree but as long as it's easy to make it work with uacpi and some people benefit from it, wahtever

#

and as long as its optional ofc

slim panther
#

hm

fiery turtle
#

ill just make something like #define uacpi_kernel_alloc(size) g_kapi->alloc(size)

slim panther
#

in the case of uacpi, fair

#

did you intend of moving it to uapi?

fiery turtle
#

in linker-only mode for now probably

#

in a similar fashion

#

just using macros

slim panther
#

okay

fiery turtle
#

do we even want a vtable mode for uapi?

slim panther
#

i don't mind

fiery turtle
#

same problem as uapi_status

#

we need an accumulating struct

slim panther
#

okay period. can we just summarize in one message what the upsides and downsides are for both approaches. i hate having to scroll between 5 discussions

fiery turtle
#

u can summarize in udrm for now sure

gentle peak
#

i personally prefer the way it currently works because it allows LTO to inline kernel APIs

fiery turtle
#

same

#

i didnt want to pay any perf price just because i decided to make a generic library

gentle peak
#

the main argument I've seen in favor of vtables is that it allows you to easily swap implementations depending on what's available, but I don't see why you couldn't just do that yourself in the kernel api impls

north holly
#

what's stopping the rusties from just having a c shim (which is actually the kernel api) that calls into their rust vtables

#

or smth

gentle peak
#

yeah exactly

fiery turtle
#

yup

gentle peak
#

that kinda thing is a bit more annoying due to rust's whole "static mut is unsafe" thing but I'm pretty sure it has atomic pointers

fiery turtle
#

fuck, implementing support for GPIO and other crap will be difficult

#

since they change the meaning of every field

#

bit offset is now the pin number, length doesnt matter whatsoever, Connection attribute resets pin offset

#

why couldnt they invent a different mechanism for this...

#
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
    Connection (
        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
            "\\_SB.GPO0", 0x00, ResourceConsumer, ,
            )
            {   // Pin list
                0x0035
            }
    ), 
    BTD3,   1, 
    Connection (
        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
            "\\_SB.GPO0", 0x00, ResourceConsumer, ,
            )
            {   // Pin list
                0x003A
            }
    ), 
    SUSB,   1, 
    Connection (
        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
            "\\_SB.GPO0", 0x00, ResourceConsumer, ,
            )
            {   // Pin list
                0x003B
            }
    ), 
    SHD3,   1, 
    Connection (
        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
            "\\_SB.GPO0", 0x00, ResourceConsumer, ,
            )
            {   // Pin list
                0x003C
            }
    ), 
    TCD3,   1
}
}

Example

#
Desktop/Dell/G5/G5 5090/67C667DAE80A
Desktop/Dell/XPS/XPS 8940/9B79A7439313
Mini Pc/AMI/Aptio/Aptio CRB/259F9FDD46E2
Notebook/Aava Mobile Oy/INARI8/INARI8-LTBN-1/A658B5B6E0CB
Notebook/BBEN/z/z10/65E372FCAFD3
Notebook/Fujitsu/LIFEBOOK/LIFEBOOK U938/71F4D08280F4
Notebook/Hewlett-Packard/Pavilion/Pavilion x2 Detachable/5850EA215153
Notebook/ilife/S/S806/7AF027A015B2
Notebook/Insyde/BayTrail/BayTrail/9F287627613B
Notebook/Lenovo/Flex/Flex 2-15/8F84E14F5157
Notebook/Lenovo/IdeaPad/IdeaPad 100S-11IBY 80R2/EE707040AC1A
Notebook/Others/Others/Others/A2330B5932DB
Tablet/Hewlett-Packard/Pavilion/Pavilion x2 Detachable/3FE302D11C0A
Tablet/Lenovo/MIIX/MIIX 3-1030 80HV/04FF5A51E4B0
Tablet/Microsoft/Surface/Surface Laptop 3/4E426AB8062D
Tablet/Microsoft/Surface/Surface Pro/773032238BB5
Tablet/Microsoft/Surface/Surface Pro 3/074C5C2E091B
#

quite a lot of users of this crap too

north holly
#

others/others/others

fiery turtle
#

the acpi spec really wants to delay 1.0 as far as possible LULW

calm latch
#

Does my laptop have this?

fiery turtle
#

now I have to carefully port the collection of ACPICA hacks to make this work in a clean way

fiery turtle
calm latch
#

Also

#

Maybe I need to dump macbook's aml

fiery turtle
#

❯ grep 'Connection (' *.dsl

#

no ur saved

calm latch
#

That's boring

fiery turtle
#

get one of those laptops

calm latch
#

I'm sad my spectre x360 died

fiery turtle
calm latch
#

It's probably interesting

fiery turtle
#

yeah

calm latch
#

But she lives on a different continent now...

fiery turtle
#

unlucky

calm latch
#

I have stuff like this ```
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (RBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0014, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\_SB.I2CB",
0x00, ResourceConsumer, , Exclusive,
)
GpioInt (Level, ActiveLow, Exclusive, PullUp, 0x0000,
"\SB.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0005
}
})
Return (RBUF) /* _SB
.I2CB.TPNL._CRS.RBUF */
}

#

Maybe I want to write i2c driver...

fiery turtle
#

yeah

flat badge
#

vtables are slightly easier if ops are optional

#

Does uacpi have any optional bindings?

vast kestrel
#

You are supposed to just stub and return not implemented error

fiery turtle
vast kestrel
#

Tbh linker gives the most flexibility, and it's like a 20 line file to make a vtable shim

fiery turtle
#

well if u count "can gracefully handle lack of" an optional binding then yes

slim panther
#

because the vtable would contain extern "C" fn()s

gentle peak
#

good point

frank canopy
#

the binding difficulty is pretty much the same for zig with either vtable or linker so I'm not impacted by that debate at least

#

maybe a bit less work to make linker bindings but not easier per se just less typing

#

just wish I could propogate error returns from callbacks but that's whatever tbh

fiery turtle
left orbit
#

it's zig abi

#

so i guess you would need to allow for custom return types for the kernel api functions

#

but i don't think you can pass error unions across C boundary anyway

#

best you can do is wrap the actual implementation in a function returning an error union and then c export fn uacpi_some_kernel_api(...) uacpi_status { some_kernel_api_wrapped(...) catch |e| return error_to_uacpi_status(e); return UACPI_STATUS_SUCCESS; // or whatever it is }

#

or just catch return UACPI_SOME_ERROR; instead of trying in the actual kernel api

frank canopy
#

and then whatever calls the extern function can detect that error being in the context later and return it instead of the default InternalError i use

#

also in this case youd be able to use the int-error conversion because while the numeric mapping of zig errors isnt guaranteed across recompiles its guaranteed within the same zig compilation unit and everything is statically linked here

#

the biggest issue is not being able to make error return traces marshal through but theres nothing that can be done about that given how those are implemented in zig

#

for reference, every zig function that returns an error takes a secret extra parameter that is an optional pointer to the stack trace which it then uses a builtin function to add its address to whenever it calls an error-returning function or returns an error directly

#

and the size of the buffer used for the traces there is determined either by just giving it a default or by static analysis

#

but afaik you cant (or shouldnt) overwrite the pointer to marshal it across so i dont think i can marshal it properly

#

what ive currently got is just a wrapper around a callback type that wraps the user context pointer in another struct that contains an optional error and the first pointer and then pass that around and use some other wrapper code. it works but its ugly af

#

(it returns iteration decision break for iteration callbacks instead of internal error for status-returning callbacks)

#

i even found a zig compiler bug in that process lmao

#

but yeah no zig error returns are part of zig's own ABI and cant be done directly through C, and zig's ABI is not meant to work across link-boundaries because zig libraries are meant to be distributed as source and included directly rather than as libraries to be linked

fiery turtle
#

@hasty plinth could u elaborate a bit on your poll vote

flat badge
#

getting rid of io mapping makes it impossible to use uacpi in userspace

#

imho aiming for minimal API is not a good idea if it impacts the functionality

vast kestrel
#

we said that iopl makes more sense for acpi runtime anyways, either that or premapping everything or lazy mapping as needed

flat badge
#

i think that's a decision that the OS should do

#

i don't buy that getting rid of these functions makes anything easier (just stub them to do nothing)

#

while it definitely makes some stuff harder for some ppl

vast kestrel
#

tbh the stub is pretty simple, *handle = (uacpi_handle_t)base, and then just (size_t)*handle + offset when accessing

fiery turtle
#

also definitely not impossible, just less convenient

vast kestrel
#

tbh given the stub is pretty simple, I don't think its that big of a deal

fiery turtle
#

that stub adds a ton of extra complexity to uacpi is the issue tbh

vast kestrel
#

not needing both the raw and mapping is a big enough of a simplification

#

I mean, isn't it similar to the system memory tho?

#

and for facs you can premap

fiery turtle
#

i can premap all fadt registers yes technically

#

or I could just not map at all :^)

vast kestrel
#

ig gas is annoying tho

#

even tho there you already do map unmap for system memory

fiery turtle
vast kestrel
#

and these are blacklisted mostly by windows and not by spec :^)

fiery turtle
#

yeah

flat badge
#

why is io special though?

#

i'd expect that it's just like mmio

fiery turtle
#

well its not i guess

frank canopy
#

mmio would be the same if you were guaranteed a certain mapping from phys->virtual address

#

or at least thats my impression

vast kestrel
#

well, on arm io is mapped as mmio

frank canopy
#

true

#

though acpi tables might handle that already

vast kestrel
#

ig the main diff is that io is pretty much always limited to a 64k address space (I think infy said acpica even asserts that)

#

so even on 32bit you can fully mmap it

frank canopy
#

ig my question is if arm acpi tables still use system io address space or just already do the mmio conversion

#

because if they already convert then the argument about arm port io being mmio doesnt really apply here imo

#

since this is for when acpi tables want to do io

vast kestrel
#

io ports on arm are mainly for pci compatibility

#

so acpi hardware on arm won't use it (if you eve have non-acpi reduced hardware)

fiery turtle
#

I think SystemIO is an x86 thing on acpi

vast kestrel
#

technically

#

because of pci bar type

frank canopy
#

and therefore the systemio map/unmap handlers being discussed here will never be called on arm and thus the in/out instructions are always a valid implementation, no?

vast kestrel
#

you don't even need io ports on arm

fiery turtle
#

but then microkernels and stuff etc etc

#

was koronas argument

frank canopy
#

yeah

#

so its only about microkernels and caching and etc etc

#

makes sense

calm latch
#

Another reason I've used iopl is that my io ports stuff is per thread, and I didn't know if io map functions would get called from gpe handlers

fiery turtle
#

its unspecified

frank canopy
#

tbh my opinion is that stuff like the io map functions etc - stuff only or primarily meant to be called to implement AML operations - should have a correspondence to a thing aml does. if aml has a thing that corresponds to needing a function like that then let the os implement it, if not then dont

#

basically if the obvious 99% implementation is a no-op then why bother

fiery turtle
#

thats basically my thinking

frank canopy
#

actually, a compromise idea here:
when does acpi logically ever unmap an io region? encountering a systemio region is enough to say it might be used and you arent likely to ever stop needing it anyway, therefore:
why not provide an optional callback when a systemio region is discovered for the first time?

#

basically go hey fyi we encountered an io region of port 0x348..0x350

fiery turtle
#

tbh its not about regions

#

its about FADT registers for the most part

#

regions are mapped on first access and umapped when destroyed

#

so basically either never or when function exits

frank canopy
#

i feel like FADT registers should be mapped once on initial load and unmapped once on uninitialize

fiery turtle
#

perhaps

frank canopy
#

the F stands for fixed for a reason, no?

#

idk

fiery turtle
#

like yes i can premap

#

but its extra logic and stuff that must be handled with care

frank canopy
#

mhm

fiery turtle
#

for abstraction that on 100% current implementations does nothing

frank canopy
#

yep

#

i voted for remove it so idk why im coming up with compromises lol

calm latch
fiery turtle
#

acpica doesnt have such abstractions for pio for example

vast kestrel
#

big brain

#

have uacpi always call the io map function once

#

mapping an entire 64k range

#

:^)

fiery turtle
#

lmao

rustic compass
#

uacpi is compileable by msvc and clang right?

fiery turtle
#

ye

rustic compass
#

ok currently having trouble compiling uacpi-rs as it aparently aborts as it cant find gcc

rustic compass
#

what compiler flags do you use to compile uacpi with msvc?

#

uacpi-rs doesnt build as either the wrapper.h or the compiler flags are incompatible with msvc

fiery turtle
rustic compass
mortal yoke
#

the current flags in uacpi-rs are gcc/clang specific yeah

rustic compass
fiery turtle
#

/runner

rustic compass
#

which set of these do i need to have the equivalent to the clang ones? /W3 /WX
/wd4200 /wd4267 /wd4244

mortal yoke
#

I don't think any of those are equivalent for them, those are for warnings

#

idk what would be the msvc equivalents of the flags used in uacpi-rs, you'd have to look them up (but also F msvc, who uses that for a kernel when you have clang/mingw gcc if you want to target pe)

calm latch
#

I compile pmOS with clang

fiery turtle
#

these are just warnings yeah

rustic compass
#

what msvc flags do i need to compile uacpi like the flags used for clang?

fiery turtle
#

default ones

rustic compass
# fiery turtle default ones

so you mean i can just ignore these flags when compiling uacpi with msvc?
"-fno-stack-protector"
"-mgeneral-regs-only"
"-nostdlib"
"-ffreestanding"

#

i dont think that that will work properly

mortal yoke
#

for a kernel I don't think it would work yeah

#

or well ig it depends on the kernel

fiery turtle
#

oh u mean for a kernel

#

no idea

rustic compass
#

i found a solution for msvc incompetence to support gcc/clangs compiler flags:

if cc.get_compiler().is_like_msvc() {
  compile_error!("uACPI does not support MSVC");
}
fiery turtle
#

not true btw

rustic compass
#

well

cc.files(sources)
        .include(format!("{uacpi_path_str}/include"))
        .define("UACPI_SIZED_FREES", "1")
        .flag("-fno-stack-protector")
        .flag("-mgeneral-regs-only")
        .flag("-nostdlib")
        .flag("-ffreestanding");

this doesnt work with msvc, it fails to build and ignores all flags

frank canopy
#

just need to actually find the right flags

#

because msvc should work

#

you probably shouldnt use it for a kernel if you can help it

#

unless you want a PE executable for some reason