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

1 messages Β· Page 12 of 1

hollow elm
#

seems to be about the same

jaunty fox
#

almost all allocations are under 2048 bytes (the number at which i don't use the predefined slabs and instead escalate to the kernel wired memory allocator.) these should do well usually

#

oh hold on, i see one ever-escalating allocation that turns up repeatedly, ramping up to well over 2048 bytes

#

i get very inconsistent results generally between runs

#

and doesn't include some sanity checks designed to check for double-free

#

i find a modest improvement with the 4k slab cache added and little difference with no freeing

#

wait, these are built with -Og

rustic compass
#

Uacpi speedrunning has been born

jaunty fox
#

i have found a major limiting factor

#

namely the IPL management

#

the build is not generally usable (it uses the lazy IPL mechanism, a mechanism i started work on which allows the issuing of writes to %cr8 to be deferred until such a time as they are actually necessary, i.e. until such a time as an interrupt exceeding the current soft IPL arrives - then it will write to %cr8 and set a flag indicating that %cr8 was raised and must fall later. this is helpful because the %cr8 write can induce a vmexit in some cases. it's broken however for edge-triggered interrupts)

fiery turtle
#

how does this one perform on your machine

#

and the other ones?

jaunty fox
#

this one is consistently around 1.4m/s

fiery turtle
#

Getting close

jaunty fox
#

before any changes, let me see what i was getting

#

before changes, [uacpi]: successfully loaded 1 AML blob, 1726 ops in 4ms (avg 370306/s)

#

so the improvement is very large indeed

#

unfortunately a huge chunk of the improvement is the lazy IPL

fiery turtle
#

3.5 times

jaunty fox
#

which is sadly broken and i fear would require significant work to fix

#

and to become nontrivial in implementation

fiery turtle
#

Is it difficult to implement properly?

jaunty fox
#

the basic idea is this: instead of strictly maintaining %cr8 (alias of the upper 4 bits of the lapic's TPR), a value in memory is maintained instead, and if an interrupt arrives which based on the value in memory should have been masked, then %cr8 is written to with the value in memory

#

and a bool is set to indicate that this happened

#

and splx() (which lowers IPL and is paired with spl raises) will test that bool, and if it's true, it will write the new lower value to %cr8

#

and then your level-triggered interrupts which were previously masked, they'll come through now

#

but the edge triggered ones won't

hollow elm
jaunty fox
hollow elm
jaunty fox
#

it really is down in large part to having a better memcpy and memset than the trivial implementation, then

#

and writing to %cr8 really is slow under VMs, slow enough that i should try to get away from it

hollow elm
#

i guess it's always a vmexit

jaunty fox
#

i saw reference to intel APICv which should help, but i don't know how new it is

#

presumably not old/widespread enough to get the benefit

hollow elm
#

does qemu use apic virtualization?

jaunty fox
#

and it looks like you need to opt in to TPR shadow

jaunty fox
jaunty fox
#

for the most common case (IPL manipulations between 0 and dispatcher level) i can avoid touching %cr8 at all

#

now i can consistently reach around 1.4m/s which is fine

north holly
torpid root
#

infy you have made uacpi a benchmark

#

as well as allocator debugger

fiery turtle
#

lmao

loud ice
#

@fiery turtle you should probably make use of a microsecond-precise timer for measuring uacpi perf

#

to reduce variance

fiery turtle
#

hm?

#

i dont use any specific timers, whatever the kernel returns

#

under the hood it could be using us converted to ns for the purposes of that api

#

the main use has been the Timer opcode in AML which expects 100ns ticks

#

oh did u think it was using ms internally? its nanoseconds converted to ms

#

(for printf specifically)

loud ice
#

ah i see

#

interesting ig

fiery turtle
#

yeah i just didnt want the log to be way too long

loud ice
#

fair enough

vale isle
#

heyy

#

it's been some time since i checked this thread out

#

what major things have happened in the last 2 months?

#

there was some work on reactos i remember?

fiery turtle
#

thread safety, lots of new api and helpers, opaque objects

vale isle
#

is 1.0 here

fiery turtle
fiery turtle
#

but getting closer

vale isle
#

ah ok cool

#

life is hard

fiery turtle
#

yes

vale isle
#

i hate the fact that i need to study this hard to get into a university to slack off for 4 years and then struggle to find a job anyway

fiery turtle
#

they had an almost ready pr but then something happened and they disappeared idk

vale isle
#

which means

#

many people who otherwise aren't interested in CS just pick CS because they can and "they don't want to waste their ranking"

#

medicine and CS are overly inflated

#

to study in a university that is not any random "apartment university" and actually has recognition abroad

#

i need to be like

#

top 1000

#

out of 3 million people entering the exam

vale isle
#

number of universities in turkey: 209

#

if you heard anything it was probably METU (middle east technical university)

frank canopy
#

oh wait, uacpi perf is largely allocator based? im using zig's std GeneralPurposeAllocator backed by a free-list based page allocator

#

or at least at this scale of benchmarking that is

fiery turtle
#

the interpreter is very allocator bound yeah

frank canopy
#

afaik its basically half of a buddy allocator but im not 100% sure what the terminology would be

fiery turtle
#

whats your current ops/s?

frank canopy
#

#1217009725711847465 message

#

949526 in ReleaseFast is my current best

fiery turtle
#

ah

#

nice

frank canopy
#

240107 in ReleaseSafe which is where im usually operating because safety checks are nice for debugging and catching issues

loud ice
fiery turtle
#

its possible with an object cache

#

since a lot of those allocations are objects

loud ice
#

you could do escape analysis meme

fiery turtle
#

lol

loud ice
#

what actually allocates in uacpi?

#

like theres a bunch of stuff that kinda has to

#

but most things shouldn't?

frank canopy
#

pooling might not be a bad thing to have in uacpi tbh since a lot of stuff is objects that presumably mostly have a known size

loud ice
#

yeah but thats a general allocator thing

#

what do the profiles look like i wonder

#

tbh the bytecode construction doesn't feel particularly fast in general

#

if i was going for maximum performance, i'd definitely try doing a compile step so that you don't jit parse aml

frank canopy
#

i mean rn we're comparing the initial load where the aml gets parsed, or at least thats what people are reporting throughput for

fiery turtle
#

Some of those could be elided probably

fiery turtle
#

But its still very tiny amount of time compared to the rest of kernel init

loud ice
fiery turtle
#

Lol

#

Basically

jaunty fox
#

i was just reading an article by a guy at bilkent

vale isle
#

lol

#

i love it when this happens

calm latch
#

What am I supposed to use instead of uacpi_namespace_node_get_object?

fiery turtle
#

purpose?

calm latch
#

I'm trying to update uACPI

#

And I have this function

uacpi_iteration_decision find_pci_device(void *param, uacpi_namespace_node *node, uint32_t depth)
{
    struct DeviceSearchCtx *ctx = param;
    uint64_t addr = 0;
    (void)depth;

    uacpi_object *obj = uacpi_namespace_node_get_object(node);
    if (obj == NULL || uacpi_object_get_type(obj) != UACPI_OBJECT_DEVICE)
        return UACPI_ITERATION_DECISION_CONTINUE;

    uacpi_status ret = uacpi_eval_integer(node, "_ADR", UACPI_NULL, &addr);
    if (ret != UACPI_STATUS_OK && ret != UACPI_STATUS_NOT_FOUND)
        return UACPI_ITERATION_DECISION_CONTINUE;

    if (addr == ctx->addr) {
        ctx->out_node = node;
        return UACPI_ITERATION_DECISION_BREAK;
    }

    return UACPI_ITERATION_DECISION_CONTINUE;
}
fiery turtle
#

for_each_device can now filter by type

#

or rather

#

for_each_child

#

with UACPI_OBJECT_DEVICE_BIT

#

will automatically do what u want

calm latch
#

uacpi_for_each_device_resource?

fiery turtle
#

uacpi_namespace_node_for_each_child

calm latch
#

Are there examples?

fiery turtle
#

managarm

#

osdev wiki

calm latch
#

I wrote this code half a year ago and don't remember what it does πŸ˜…

fiery turtle
#

looks like it finds the address of a pci device

frank canopy
#

theres even a dedicated function for adr iirc too

#

plus a function to get the type of a node

fiery turtle
#

for_each_child can filter by node type already but yeah

calm latch
#
    if (class == 0x06 && subclass == 0x04) { // Host bridge
        struct DeviceSearchCtx ctx = {
            .addr = d->device << 16 | d->function,
            .out_node = NULL,
        };
        uacpi_namespace_for_each_child_simple(node, find_pci_device, &ctx);

        uint8_t secondary_bus = pci_secondary_bus(c);
        printf("PCI secondary bus %x\n", secondary_bus);

        uacpi_pci_routing_table *pci_routes;
        uacpi_status ret = uacpi_get_pci_routing_table(ctx.out_node, &pci_routes);
        if (ret != UACPI_STATUS_OK) {
            fprintf(stderr, "Warning: Could not get PCI routing for root bridge bus %0x: %i\n", bus, ret);
        } else {
            parse_interrupt_table(g, secondary_bus, pci_routes);
            uacpi_free_pci_routing_table(pci_routes);
        }

        check_bus(g, secondary_bus, d, ctx.out_node);
    }
frank canopy
#

though you probably want to just use the filter

calm latch
#

Wiki has this

    uacpi_namespace_for_each_child(
        uacpi_namespace_root(), acpi_init_one_device, UACPI_NULL,
        UACPI_OBJECT_DEVICE_BIT, UACPI_MAX_DEPTH_ANY, UACPI_NULL
    );
fiery turtle
#

thats it

calm latch
#

Oh and I remove this ```c
uacpi_object *obj = uacpi_namespace_node_get_object(node);
if (obj == NULL || uacpi_object_get_type(obj) != UACPI_OBJECT_DEVICE)
return UACPI_ITERATION_DECISION_CONTINUE;

fiery turtle
#

yup

calm latch
#

Ok it seems to compile

#

Thanks

fiery turtle
#

lets see your ops/s

calm latch
#

(for now)

#

(I couldn't get it to work so I'm updating it)

#

New uacpi_kernel_log?

fiery turtle
#

hm?

calm latch
fiery turtle
#

jesus how old is yor uacpi lol

#

u need #define UACPI_FORMATTED_LOG or whatever

calm latch
#

Will it format itself if I don't pass that?

#

My printf is 'ok'

fiery turtle
#

yeah

#

u dont have a good printf in userspace?

calm latch
#

I wrote it myself

fiery turtle
#

why not reuse existing libc

calm latch
#

So it can't be fully trusted

#

Idk

#

I'm writing my own

fiery turtle
#

anyway then just keep this logger

frank canopy
#

the fact that uacpi can do its own printf format is so nice for my case since zig's format doesnt use the same format string format as c does and this way i dont need to implement it in a shim somewhere

fiery turtle
#

yeah language interop is a big reason why it was added

calm latch
#

Do I need UACPI_KERNEL_INITIALIZATION?

#

Atm I just call ```c
uacpi_initialize(&init_params);
uacpi_namespace_load();
uacpi_set_interrupt_model(UACPI_INTERRUPT_MODEL_IOAPIC);
// init pci
uacpi_namespace_initialize();
uacpi_finalize_gpe_initialization();

#

And uacpi_initialize isn't working...

frank canopy
#

uacpi_initialize takes a flags bitmask now

#

if youre passing rsdp theres a kernel_api function you implement for that

frank canopy
calm latch
#

Oh uacpi_kernel_get_rsdp

fiery turtle
calm latch
#

What do I need to give it in uacpi_kernel_get_thread_id()?

fiery turtle
#

pthread_self?

calm latch
#

Ok

#

I'm getting internal error

fiery turtle
#

mutex acquire failed?

#

perhaps

calm latch
fiery turtle
#

thats the only path that may fail there

calm latch
fiery turtle
#

fix your nanoseconds_since_boot btw

calm latch
#

My lapic is too slow

#

Event initialization has to do with interrupts, right?

fiery turtle
#

well it says right there

#

unable to install interrupt handler

calm latch
fiery turtle
#

kvm clock -> invariant tsc -> hpet -> ACPI PM timer -> manual tick counting

calm latch
#

Thonk time to write another server

fiery turtle
#

wtf

calm latch
#

I had HPET in userspace

fiery turtle
#

bruh imagine the latency of that

calm latch
#

Maybe I'll add invariant tsc

#

Since hpet requires ioapic

#

Which I also manage from userspace...

fiery turtle
#

reading hpet counter requires quite literally nothing

calm latch
#

But it needs interrupts.....................

fiery turtle
#

it needs them if you need them

#

which u dont

#

for interrupts u use lapic

calm latch
#

And it has 64 bit counters

#

Ok

#

I'll add a driver for that

slim panther
#

that's news

calm latch
#

No I've been using it before for event timer

fiery turtle
calm latch
#

Like for sleep()

#

And then I've switched/unified everything to use lapic after porting to risc-v which only had local timers

fiery turtle
#

you're mixing up rescheduling timers vs current time readback

#

those are unrelated concepts

calm latch
#

I know

#

I'm just updating a global counter at the moment

#

From lapic interrupts

#

On bsp core

#

Which are 10-100* ms

#

(*which could be anything since the kernel is nonpreemptive)

#

(and it's running in single shot mode)

#

anyways

#

I think it initialized

#

But it doesn't shut down 😦

fiery turtle
calm latch
#

No

#

I'll fix it in 10 minutes - 1 month

fiery turtle
#

not bad

calm latch
#

Since I have homework due today

fiery turtle
#

as accurate as your timer readback LULW

calm latch
calm latch
#

+- 10 seconds accuracy is fine for most use cases

fiery turtle
#

indeed

calm latch
#

It was working with the old version

fiery turtle
#

well all it does to shutdown in qemu is port io

#

so debug your port io

calm latch
#

But it did get interrupt from the power button

calm latch
fiery turtle
#

add printfs

#

or at least addr2line where its stuck

#

i remember someone having a similar bug

#

i dont recall how they fixed it tho

calm latch
#

It's not stuck

#

I think my sleep is broken

fiery turtle
#

bruh

calm latch
fiery turtle
#

maybe its trying to sleep for a month meme

calm latch
#

Ok I think I'll finish the uni stuff and try to fix timers (in about 1 hour)

#

Or I could keep procrastinating Thonk

#

I think it was indeed sleeping for a month KEKW KEKW KEKW

#

I have been passing size_t to a function which takes uint64_t

#

And it probably got garbage in the upper 32 bits

fiery turtle
#

lol

#

fixed upstream

fiery turtle
calm latch
#

My fork is broken

#

It corrupts heap

#

(I think)

#

I haven't investigates

#

And AHCI driver forks for every controller it finds

fiery turtle
#

this kernel might be more unstable than obos

calm latch
#

The kernel is quite stable

#

(to my standards)

#

The userspace though...

fiery turtle
#

is fork done via userspace?

calm latch
#

No/yes

#

My fork clones 2 threads

#

Because each process has a library threads

#

So that library thread saves the state of the forking thread, clones itself, and recreates the thread that forked

#

And that saves all registers to .data

#

Which are defined as 16 longs

fiery turtle
#

bruh why is this so complicated

calm latch
#

Which are 32 bit on i686

#

But I haven't added a special case for that in kernel

#

(I think this is what's happening)

calm latch
calm latch
calm latch
#

So I came up with this

#

(though I didn't implement signals yet)

#

Lol even more things are failing now...

#

But it doesn't wait for a month anymore tabien

calm latch
#

Ok, time to fix nanoseconds_since_boot

calm latch
#

Are there 32 bit hpet systems in existence?

fiery turtle
#

yes

gentle peak
#

yeah, my dev system (b550) has a 32 bit hpet

calm latch
#

oof

#

How many seconds is that? Thonk

gentle peak
#

I think it was 42 seconds?

#

idk I don't use hpet for anything other than tsc calibration

#

actually no I think that was a different system, this one was 5 minutes

calm latch
#

I think I can just detect rollovers periodically

#

Wiki says TSC is unreliable

gentle peak
#

as long as the maximum time between reads is less than the rollover time you're fine

gentle peak
#

there's a cpuid bit that tells you whether the tsc is usable for general timekeeping and it's set even on the oldest systems I own

fiery turtle
calm latch
#

And it's a couple of MSRs...

#

Ok I'll support that instead

#

It seems trivial

gentle peak
#

tsc used to be a simple cycle counter which could change freq which is why it was unreliable, but for decades now it's been a fixed frequency

fiery turtle
jaunty fox
gentle peak
# calm latch It seems trivial

yeah just rdtsc, also has the advantage that you don't need actual syscalls for time stuff. to get the frequency just read both it and a known-frequency clock like hpet before and after sleeping a few milliseconds

#

on newer Intel systems and in hypervisors cpuid can tell you the freq but that's not ubiquitous yet

calm latch
#

I'm callibrating LAPIC with PIT anyway

#

So I can measure TSC during that as well

calm latch
#

Is it synchronized between cores?

#

Wiki says it isn't

#

And I haven't reached to the explanation in SDM...

#

Oh no

per-CPU differences in TSC values in a NUMA system

gentle peak
#

important distinction there: "in a NUMA system"

calm latch
#

So multi CPU

gentle peak
#

I'm not sure if it's explicitly guaranteed anywhere but I've never seen a system where the CPUs in a single package have different TSC values or frequencies

gentle peak
calm latch
#

I have Ryzen 9, it has 2 CCDs

gentle peak
#

Still not NUMA

calm latch
#

But I think it's not NUMA

calm latch
gentle peak
#

oh yeah multi socket systems are more likely to be numa

calm latch
#

But I don't have those

gentle peak
#

but then again you'll most likely never encounter those; the approach I take is to simply not use any CPUs that aren't in the same package as the boot CPU

calm latch
#

So I just rdtsc on boot cpu and use it as the reference?

gentle peak
#

that'll work on basically any consumer system yeah

calm latch
#

The synchronization of TSC adjustment can be simplified by using the 64-bit IA32_TSC_ADJUST MSR

#

Ok that doesn't apply to me I think

#

Also I can add a mechanism to syncronize the timers

gentle peak
#

that just helps with increasing/decreasing the tsc value by the same decrement on every cpu

#

for stuff like NTP I think?

#

or just adjusting system time in general

calm latch
#

Hmm I think I can just replace LAPIC with TSC deadline...

gentle peak
calm latch
gentle peak
#

for example, my Ryzen 5xxx doesn't support it

calm latch
gentle peak
#

yep

calm latch
#

And I've recently bought b550 mobo

#

Ok

#

It makes it easy (?)

#

(I need to stop saying that and keep reeding SDM)

vast kestrel
#

technically I don't think there is any guarantee in the spec about tsc being synchronized between cores

calm latch
#

Do I need to enable it or something?

vast kestrel
#

Practically because it's a single timer for all cores in a single socket it is synchronized

#

Invariant/constant tsc just exists, it just means that's how the timer behaves

calm latch
#

The invariant TSC is based on the invariant timekeeping hardware (called Always Running Timer or ART), that runs
at the core crystal clock frequency. The ratio defined by CPUID leaf 15H expresses the frequency relationship
between the ART hardware and TSC.

vast kestrel
#

On some newer cpus you can use the cpuid to calculate it directly, on others you can't

gentle peak
gentle peak
vast kestrel
#

Tbh I would dig in the lkml instead, alot of guarantees only appear there and no where else

#

And if Linux does synchronize it at boot then there is most likely a reason (which might just be numa, but that's why you wanna check why they added it)

frank canopy
gentle peak
#

it does, just not the cpuid leaf that tells you the freq

vast kestrel
#

Yeah they don't

#

I don't think it fully holds to invariant tsc

gentle peak
#

the invariant TSC itself is still supported

vast kestrel
#

It might be constant tho

#

Invariant also works across P/C states

gentle peak
#

you just need to calibrate it to figure out the freq

gentle peak
vast kestrel
#

Then why didn't they enable it lol

gentle peak
#

they do

vast kestrel
#

I mean the cpuid leaf

frank canopy
#

I wish there was a way to detect constant tsc without requiring the power p/c state stuff for invtsv tbh. unless there is and I don't know it anyway

gentle peak
#

they set the bit that indicates it's supported, they just don't have the frequency leaf

vast kestrel
#

Ah

#

I think early ryzens also didn't have invariant tsc

#

And I thought you were talking about that

frank canopy
#

the lack of frequency leaf i knew because its making things more annoying to me because I only have amd cpus lol

north holly
#

My cpu is Haswell so it doesn't have invtsc

#

Intel i5 4590T

vast kestrel
#

Yeah it was before the bit existed I think

#

It does have constant tsc

gentle peak
vast kestrel
#

I am also certain it doesnt have it, but I don't have a Ryzen to test rn

#

I think since Prescott the tsc is constant

#

But for a while it wasn't invariant and would change across C states

#

Or maybe it was during sleep idr

hollow elm
calm latch
#

Can I assume rdtsc always exists?

hollow elm
#

er, no, that's constant tsc

north holly
hollow elm
north holly
#

Constant TSC is between C states n stuff right

vast kestrel
#

Could be that

hollow elm
#

so acpi sleep etc

frank canopy
#

yep

vast kestrel
#

Ok so it seems nehalem and up should have invariant tsc across p/c states

#

But not across s states

frank canopy
#

invariant is across s states and constant is p/c states afaik

#

the problem is iirc theres no way to check for constant unless you also have invariant

hollow elm
#

solution: ```
if(invariant)
return;
if(!constant)
panic();
turn_off_acpi_sleep();

vast kestrel
#

before nehalem it seems that the tsc was constant across everything but c states excluding hlt state

#

Idk if there were other sleep states tbh

north holly
gentle peak
vast kestrel
#

But I am almost sure that before Prescott it wasn't constant at all

north holly
#

Although I doubt it

gentle peak
north holly
#

Then constant TSC is what

gentle peak
#

I think it's the other way around, constant TSC is consistent as long as you don't change C-states and invariant TSC is always consistent

vast kestrel
#

The hell is T state

vast kestrel
gentle peak
#

yeah that's constant I think

#

and invariant is the same but you are allowed to enter sleep states

vast kestrel
#

Technically hlt enters a c state, it's just that in the cpu impl case it also increments the tsc normally

north holly
#

Invariant also means it's synchronized with all other CPUs

calm latch
#

What was the trick for this, but without overflowing?
return rdtsc() - boot_tsc * 1000000 / tsc_ticks_per_1_ms;

vast kestrel
north holly
#

Right

#

?

calm latch
#

(except missing parenthesis)

north holly
gentle peak
#

if it is I can't find it

vast kestrel
#

I think the spec says nothing

north holly
#

If Linux and windows assume it then surely you can too

vast kestrel
#

But practically every single socket cpu has a single tsc

north holly
#

But idk if they assume it

vast kestrel
#

I am not sure if they do

#

Linux almost certainly does not because of numa, and they might as well always sync it just in case

gentle peak
#

I forgot the formulas for how to do that but they're in this server somewhere

vast kestrel
#

Imagine using anything but the acpi timer smh

calm latch
#

But will I have 128 bit multiplication in i686? Thonk

vast kestrel
#

You can also always use the hypervisor provided timer :^)

#

32bit is for the weak

calm latch
#

I have a specific hardware which I want to target

gentle peak
calm latch
vast kestrel
#

Might as well use i286

calm latch
#

It's Celeron M

#

Or Celeron D?

hollow elm
#

i think on 32-bit it'll be 4 muls and some additions for a 64x64=128 bit multiplication

calm latch
#

I don't remember

gentle peak
#

actually iirc GCC doesn't support 128 bit arithmetic at all on <64 bit arches

#

as in the int128 type doesn't exist

calm latch
#

(I have to take another look tomorrow)

#

I'm using clang

gentle peak
#

then idk

calm latch
#

fuck gcc

#

it's buggy and obnoxious

gentle peak
#

agree but I would like my kernel to at least be compilable with it

vast kestrel
#

GCC is based since it has the new struct changes in c23 already

calm latch
#

But I would need to rebase my patches on the latest version

hollow elm
#
<source>:4:22: error: __int128 is not supported on this target
    4 |     return (unsigned __int128)a * (unsigned __int128)b;
      |                      ^
``` clang also doesn't support it on 32-bit
gentle peak
# gentle peak then idk

the only times I've messed around with 32 bit is while writing for the absolute lowest common denominator (Compaq Deskpro 386) so I didn't have to deal with tsc

calm latch
#

Otherwise atm I have gcc 12

vast kestrel
#

The last time I messed around with not 64bit is either using armv7-m or an 8bit cpu

calm latch
vast kestrel
# fiery turtle which

Where multiple definitions of the same struct are allowed (as long as they have the exact same fields)

fiery turtle
#

why is that based

vast kestrel
#

It allows to have generic macros without also needing a define if the type

gentle peak
#

oh yeah same even in that one I used 64 bit but for timers as fast as the tsc you really want to be able to have 128 bit intermediate values

vast kestrel
#

So things like a result type are easy to impmement

vast kestrel
#

Like a imagine a macro defining ```c
struct result_int { err_t err; int value; }

#

Where the int is pasted from a macro parameter

#

So RESULT(int)

#

You can not use that macro in both the function signature and when returning

#

And it would be the exact same type

hollow elm
#

amazing, thanks discord for the code block

vast kestrel
#

RESULT(int) my_func() {
return OK(int, 123);
}

And OK can be (RESULT(int)){.value = 124};

fiery turtle
#

ah

#

cool

vast kestrel
#

Like it's almost entirely for macros defining structs to have a easier time

gentle peak
#

every time I hear something about c23 I didn't know before the urge to target it in my next project gets more intense

vast kestrel
#

I mean ignoring the cool libc additions, I would take it just for the #embed lol

gentle peak
#

the only thing stopping me right now is that afaik the implementations aren't fully complete yet

vast kestrel
#

So many projects where I need to setup an objcopy just for thatv

#

Yeah both clang and GCC are missing stuff

#

Also I am not sure if anything fully added the libc additions

gentle peak
vast kestrel
#

Ouch

#

Or well

#

I have at works projects where we need to include mbs of files in the binary

gentle peak
#

works fine enough for small files and embedding large files would give me the ick anyway

vast kestrel
#

Which can take literal minutes to compile sometimes

gentle peak
#

oh yeah fair enough, the largest files I've ever needed to embed are like 4k-16k

vast kestrel
#

In one project we have an entire rootfs embedded in the binary (we really like standalone static binaries)

#

The bit precise integers are also cool

#

Especially cause no integer promotion

#

Oh and yeah, typed enum

#

Wait that's the uacpi channel wtf

calm latch
#

@fiery turtle

fiery turtle
#

the record on this server is 1.5M/s

#

so ur a bit behind

calm latch
#

What does that even mean?

north holly
#

I am 2nd worst

calm latch
#

Am I the 1st worst?

north holly
#

Feels bad to be nyaux though

#

I thought mine was bad

#

Which it is

#

But nyaux' was terrible

calm latch
#

I'm gonna recompile to 64 bits...

fiery turtle
gentle peak
#

It's mostly an allocator and mutex benchmark right?

fiery turtle
#

nah

#

memset+memcpy/allocator

gentle peak
#

ah

calm latch
#

I'm using dlmalloc

vast kestrel
fiery turtle
#

lmao

north holly
#

I think uacpi's memset and memcpy are a big culprit for me

#

My normal ones are accelerated

#

But idk if uacpi uses those ones

gentle peak
#

I kinda wanna try integrating it into my kernel just for the benchmark but so far I've managed to get away with no real kernel vmm (all kernel allocations are <=PAGE_SIZE and in hhdm) and I'd like to keep it that way

frank canopy
fiery turtle
north holly
#

Yeah ik

fiery turtle
#

look at the libc header

frank canopy
north holly
#

I override livc

#

Libc

#

I think

#

I indeed do

#
void *uacpi_memcpy(void *dest, const void* src, size_t sz)
{
    return memcpy(dest,src,sz);
}
void *uacpi_memset(void *dest, int src, size_t cnt)
{
    return memset(dest, src, cnt);
}```
frank canopy
#

zig's builtins might be accelerated but idk, i also have all simd/vector things turned off in my kernel anyway so idk how much it can accel apart from rep instruction stuff

north holly
#

that's probably not the culprit

frank canopy
#

well in that case it is using yours

north holly
#

I use rep movsb and friends

north holly
#

but memcmp

int uacpi_memcmp(const void *src1, const void *src2, size_t cnt)
{
    const uint8_t* b1 = (const uint8_t*)src1;
    const uint8_t* b2 = (const uint8_t*)src2;
    for (size_t i = 0; i < cnt; i++)
        if (b1[i] < b2[i])
            return -1;
        else if (b1[i] > b2[i])
            return 1;
        else
            continue;
    return 0;
}```
#

does this

#

which isn't very efficient

frank canopy
#

id assume zig uses rep movsb but im legit not sure

north holly
#
void *uacpi_memmove(void *dest, const void* src, size_t len)
{
    if (src == dest)
        return dest;
    // Refactored from https://stackoverflow.com/a/65822606
    uint8_t *dp = (uint8_t *)dest;
    const uint8_t *sp = (uint8_t *)src;
    if(sp < dp && sp + len > dp)
    {
        sp += len;
        dp += len;
        while(len-- > 0)
            *--dp = *--sp;
    }
    else
        while(len-- > 0)
            *dp++ = *sp++;
    return dest;
}```
#

memmove can probably be improved

fiery turtle
#

how any of this works

north holly
#

what

frank canopy
#

oh right its #defines i forgot about that

north holly
fiery turtle
north holly
#
#define uacpi_memcpy uacpi_memcpy
#define uacpi_memset uacpi_memset
#define uacpi_memmove uacpi_memmove
#define uacpi_memcmp uacpi_memcmp
#define uacpi_strcmp uacpi_strcmp
#define uacpi_strncmp uacpi_strncmp
#define uacpi_strnlen uacpi_strnlen
#define uacpi_strlen uacpi_strlen
#define uacpi_snprintf uacpi_snprintf```
#

I do fnuy macro stuffs

fiery turtle
#

why extra indirection lol

#

just do #define uacpi_memcpy __builtin_memcpy etc

calm latch
fiery turtle
#

yeah only 3 orders of magnitude behind managarm meme

north holly
#

I am missing memmove

#

and strnlen

fiery turtle
north holly
#

they return a bool instead of int

fiery turtle
#

memcpy and memset should still be builtin

calm latch
#

Stack allocator?

fiery turtle
gentle peak
north holly
#

you're right

#

although,

#

I'll fix it later

fiery turtle
#

managarm and keyronex are both at 1.5M, I think for keyronex reducing vmexits for cr8 writes and improving memcpy was the fix

#

initially keyronex was at 250K i think

#

oh and a 4k slab

north holly
#

I forgor how much mine was

fiery turtle
#

#1217009725711847465 message

#

the big flex

fiery turtle
calm latch
#

That reading was wrong

north holly
#

my cpu does indeed have invtsc

fiery turtle
#

+invtsc

calm latch
#

(and it didn't use tsc)

fiery turtle
#

in qemu

north holly
#

but idk why linux doesn't report it

gentle peak
north holly
#

in /proc/cpuinfo

fiery turtle
#

it just gives u the values to convert tsc to elapsed ns

gentle peak
#

Add support for kvmclock or use -M migratable=off (both only have an effect if kvm is used)

calm latch
#

I wasn't using KVM

fiery turtle
#

wait why

gentle peak
#

I haven't found a way to get QEMU to report invariant TSC while using TCG

fiery turtle
#

for no kvm 20k is a decent result

north holly
#
oberrow@AcerAIO:~$ cpuid -l0x80000007
CPU 0:
   RAS Capability (0x80000007/ebx):
      MCA overflow recovery support = false
      SUCCOR support                = false
      HWA: hardware assert support  = false
      scalable MCA support          = false
   Advanced Power Management Features (0x80000007/ecx):
      CmpUnitPwrSampleTimeRatio = 0x0 (0)
   Advanced Power Management Features (0x80000007/edx):
      TS: temperature sensing diode           = false
      FID: frequency ID control               = false
      VID: voltage ID control                 = false
      TTP: thermal trip                       = false
      TM: thermal monitor                     = false
      STC: software thermal control           = false
      100 MHz multiplier control              = false
      hardware P-State control                = false
      TscInvariant                            = true
      CPB: core performance boost             = false
      read-only effective frequency interface = false
      processor feedback interface            = false
      APM power reporting                     = false
      connected standby                       = false
      RAPL: running average power limit       = false
      fast CPPC                               = false```
hollow elm
#

also fun fact, tcg doesn't explicitly emulate invariant tsc, but the tsc is just the host's tsc value on x86_64 hosts so if the host has an invariant tsc the tcg guest does too :^)

gentle peak
#

yeah I just decided to assume the TSC was invariant if kvmclock isn't supported, no matter what CPUID says

fiery turtle
#

u support kvmclock also?

gentle peak
#

yeah

fiery turtle
#

damn

#

second kernel here

#

do u have a link to your kernel btw

gentle peak
#

if it's available I use it, if not TSC regardless of what CPUID says

#

nope, it's a private repo and will likely stay as such for a very long time

fiery turtle
#

why is that

hollow elm
gentle peak
#

just personal preference, I like to keep things private until they're usable

fiery turtle
hollow elm
#

a little thing called vdso

fiery turtle
#

tru

gentle peak
#

like my kernel can do quite a lot but it's not at the point where I'd like to make it public

fiery turtle
#

works until the clock source in linux is assumed unstable

#

at which point it switches to hpet

#

and vsdo no workie

calm latch
#

It didn't work 😦

fiery turtle
#

it?

calm latch
#

Am I checking it wrong?

fiery turtle
#

what did u change

calm latch
#
    u64 c = cpuid(0x80000007);
    if (c & (1 << 8)) {
        global_logger.printf("[Kernel] Info: TSC Invariant bit is set\n");
fiery turtle
#

your qemu command line..

vast kestrel
#

Qemu doesn't pass invariant tsc by default

calm latch
# fiery turtle what did u change

sudo qemu-system-x86_64 -device pcie-root-port,id=root_port1,port=0x10,chassis=1,multifunction=on,slot=1,bus=pcie.0,addr=0x10 -device x3130-upstream,id=switch_upstream,bus=root_port1,addr=0x0 -device xio3130-downstream,id=switch_downstream1,bus=switch_upstream,chassis=3,addr=0x1 -device xio3130-downstream,id=switch_downstream2,bus=switch_upstream,chassis=4,addr=0x2 -device pcie-pci-bridge,id=pci_bridge1,bus=switch_downstream1,addr=0x0 -device pcie-pci-bridge,id=pci_bridge2,bus=switch_downstream2,addr=0x0 -device e1000e,id=nic1,bus=pci_bridge2,addr=0x0 -drive file=limine/pmOS.iso,if=none,id=hdd0 -device ide-hd,drive=hdd0 -M q35 -smbios type=0,uefi=on -bios ovmf-x86/OVMF.fd -m 2G -smp 4 -serial stdio -cpu host,+invtsc -enable-kvm

fiery turtle
#

-M migration=off

gentle peak
#

I keep forgetting whether it's migration or migratable

hollow elm
#

iirc migratable?

fiery turtle
#

could be the latter

calm latch
#

qemu-system-x86_64: Property 'pc-q35-6.2-machine.migration' not found

fiery turtle
#

migratable

hollow elm
#

also isn't it a property of cpu and not machine?

fiery turtle
#

machine i think

calm latch
#

bruh qemu-system-x86_64: Property 'pc-q35-6.2-machine.migratable' not found

fiery turtle
#

hm

hollow elm
#

-cpu migratable=off

fiery turtle
#

u have an old ass qemu btw

gentle peak
#

is it migrateable?

#

if that doesn't work either it's probably just because your QEMU is too old

hollow elm
#

from managarm's qemu script cpu_model = "host,migratable=no"

calm latch
#

I'll try it baremetal

#

on my laptop

hollow elm
calm latch
#

I've been implementing PCI interrupts routing

vast kestrel
#

That's enough to have the bit on my setup

#

Aka just the host and invtsc

fiery turtle
#

@vast kestrel btw what happened to AML OS?

vast kestrel
#

Never had the chance to continue sadly

fiery turtle
#

F

vast kestrel
#

Like I had a super busy time at work

fiery turtle
#

happens

vast kestrel
#

And the last week I am on vacation but too burned out to really work

fiery turtle
#

my vacation starts this saturday so im happy

vast kestrel
#

Noice

fiery turtle
#

Btw @winter orbit any updates regarding ReactOS? I think you mentioned it was almost ready or w/e but then something happened?

winter orbit
#

I’m basically rewriting the entirety of hal ACPI and pci at the same time

vast kestrel
#

Lmao

fiery turtle
#

damn

calm latch
#

How fun, it (uACPI) died

fiery turtle
#

make sure to fetch the latest uacpi, a lot has changed since then!

winter orbit
#

It workwd though for what I needed ROS to do

fiery turtle
#

try managarm on this pc meme

#

(laptop)

vast kestrel
calm latch
#

And it didn't detect TSC either

fiery turtle
#

didnt it use to work lol

calm latch
#

Bare metal

winter orbit
#

Here’s some screen shots using uACPI though

fiery turtle
#

daaamn

winter orbit
#

One on the left finally detects the touch screen

fiery turtle
#

80 fps is quite decent

winter orbit
#

One on the right is using the gpu properly

fiery turtle
winter orbit
#

Our current ACPI driver doesn’t even detect the touch screen

#

so.. yes

fiery turtle
#

big

#

amazing work

calm latch
winter orbit
#

Should really be saying that to you lol uACPI works great

north holly
winter orbit
#

I’m almost done porting it to windows 10

north holly
fiery turtle
calm latch
fiery turtle
winter orbit
#

Wanna see something funnier

fiery turtle
#

yes!

winter orbit
#

StarCraft 2

fiery turtle
#

lol

#

damn

#

can it run crisis tho

winter orbit
#

yeah

vagrant hull
#

only gamers get that joke 😏

fiery turtle
#

its a reference to one of their vids actually running crisis on reactos

calm latch
vagrant hull
#

and i am referencing Jensen Huang being cringe

calm latch
#

How do I compile with dwarf?

fiery turtle
fiery turtle
#

still crazy

winter orbit
#

yeah turns out GPUs were getting broken on pci, Hal, ACPI etc

#

So I’m rewriting stufff to be more like windows 10

#

That’s why it’s taking so long, it’s kinda a pain oof and will probably still take many months

fiery turtle
#

daamn

#

I wanna hear progress reports tho meme

winter orbit
#

I’ll make a thread next interesting thing happens and start posting on it

fiery turtle
#

oh cool

winter orbit
#

My bad I get tunnel vision

fiery turtle
#

pls do

fiery turtle
calm latch
#

I don't remember

fiery turtle
#

i wonder what sort of ops/s is reactos getting

calm latch
#

I think it crashed in prepare_table_load

#

Ok but seriously how do I make objdump show code with clang

fiery turtle
calm latch
#

??:?

fiery turtle
#

do u compile with -g?

calm latch
#

Yes

fiery turtle
#

try -ggdb3

calm latch
#

Still nothing

fiery turtle
#

is it even a valid rip

calm latch
#

Ok, llvm-objdump worked for some reason

calm latch
#

It crashed in ```x86asm
; return cause != UACPI_TABLE_LOAD_CAUSE_INIT;
224683: 41 83 fe 02 cmpl $0x2, %r14d
224687: 41 0f 94 c6 sete %r14b
; in_method->code = dsdt->definition_block;
22468b: 48 8d 43 24 leaq 0x24(%rbx), %rax
22468f: 48 89 45 c8 movq %rax, -0x38(%rbp)
; in_method->size = dsdt->hdr.length - sizeof(dsdt->hdr);
224693: 8b 43 04 movl 0x4(%rbx), %eax
224696: 83 c0 dc addl $-0x24, %eax
224699: 89 45 d8 movl %eax, -0x28(%rbp)
; in_method->named_objects_persist = UACPI_TRUE;

#

uACPI/source/interpreter.c:1260

fiery turtle
#

whats the cr2 btw

calm latch
#

4

fiery turtle
#

so the dsdt pointer was null?

calm latch
#

Idk

#

It printed half of the tables and then crashed

fiery turtle
#

this code is executed way past that

#

i mean the table printing

calm latch
fiery turtle
#

can u recheck your mapping callback?

calm latch
#

What do I need to check?

fiery turtle
#

whats missing

calm latch
#

The last one looks cut off

fiery turtle
#

facs doesnt have those fields

#

so they arent printed

#

its special cased in the dump_table_header fn

#

so it dies when trying to load the DSDT, when preparing it for load

#

u can add a printf to uacpi_execute_table to see the value of tbl

#

btw can u not add a trailing newline to uacpi logs because it looks ugly

calm latch
fiery turtle
#

aa000?

calm latch
#

It's normal

#

If it's from the mapping callback

fiery turtle
#

well

#

looks like a stack corruption or something similar, because mapping is checked for nulls

#

i can see it propagating the error

#
        tbl->ptr = uacpi_kernel_map(tbl->phys_addr, tbl->hdr.length);
        if (uacpi_unlikely(tbl->ptr == UACPI_NULL))
            return UACPI_STATUS_MAPPING_FAILED;
#

maybe log all the mappings happening?

calm latch
#

Does it call unmap right after mapping?

#

Lol how do I dump the tables

#

From Windows

fiery turtle
fiery turtle
#

acpixtract -a dump.txt

fiery turtle
#

that might be a heap corruption that happens to overwrite the table's reference count value

#

try increasing UACPI_STATIC_TABLE_ARRAY_LEN

#

to like 128 or something

#
[uACPI][INFO] RSDP 0x00007FFE47B42BE0 00000024 v02 (uOEMID)
[uACPI][INFO] XSDT 0x0000611000000CC0 000000DC v02 (LENOVO uTESTTBL)
[uACPI][INFO] DSDT 0x0000630000000400 0000E586 v02 (LENOVO AMD_EDK2)
[uACPI][INFO] FACP 0x00006120000004C0 00000114 v06 (uOEMID uTESTTBL)
[uACPI][INFO] SSDT 0x000061E000000080 000009AE v01 (LENOVO UsbCTabl)
[uACPI][INFO] SSDT 0x000062D000000400 00008416 v02 (LENOVO AmdTable)
[uACPI][INFO] SSDT 0x000062A000000200 0000547E v02 (LENOVO AmdTable)
[uACPI][INFO] SSDT 0x0000619000000A80 000003D5 v02 (LENOVO Tpm2Tabl)
[uACPI][INFO] SSDT 0x000061B000000080 00000655 v02 (LENOVO OEMPMF  )
[uACPI][INFO] SSDT 0x000061F000000080 00000BEB v02 (LENOVO CPMDFIG4)
[uACPI][INFO] SSDT 0x0000626000000100 00002C36 v02 (LENOVO CDFAAIG2)
[uACPI][INFO] SSDT 0x000062E000000400 00009F19 v02 (LENOVO CPMCMN  )
[uACPI][INFO] SSDT 0x000061F000000E80 00000CC7 v02 (LENOVO NVME    )
[uACPI][INFO] SSDT 0x000061E000000C80 0000098D v02 (LENOVO GpMsSsdt)
[uACPI][INFO] SSDT 0x0000608000000220 00000058 v02 (LENOVO GPP1    )
[uACPI][INFO] SSDT 0x00006080000002A0 00000058 v02 (LENOVO GPP0    )
[uACPI][INFO] SSDT 0x0000622000000100 00001678 v02 (LENOVO UPEP    )
[uACPI][INFO] SSDT 0x000061C000000080 0000074E v02 (LENOVO THERMAL0)
[uACPI][INFO] SSDT 0x0000621000000100 0000108F v02 (LENOVO GPP_PME_)
[uACPI][INFO] SSDT 0x000062D00000A400 00009B61 v02 (LENOVO INTGPP03)
[uACPI][INFO] SSDT 0x000062A000006200 000052B4 v02 (LENOVO INTGPP01)
[uACPI][INFO] SSDT 0x000061E000001880 00000B69 v02 (LENOVO CPMGPIO0)
[uACPI][INFO] SSDT 0x0000611000000E00 000000E7 v02 (LENOVO MHSP    )
[uACPI][INFO] SSDT 0x000061D000000080 0000097B v02 (LENOVO CPMMSOSC)
[uACPI][INFO] SSDT 0x000060D0000002B0 00000090 v02 (LENOVO CPMMSLPI)
[uACPI][INFO] SSDT 0x0000621000001500 00000FDF v02 (LENOVO CPMACPV5)
[uACPI][INFO] FACS 0x0000606000000320 00000040
[uACPI][INFO] successfully loaded 23 AML blobs, 10241 ops in 259ms (avg 39409/s)
[uACPI][INFO] namespace initialization done in 22ms: 106 devices, 1 thermal zones
#

@calm latch

calm latch
#

Hmm

#

Ok it's getting too late

#

I'm gonna try it tomorrow

fiery turtle
#

lets try more stuff tomorrow yeah

fiery turtle
#

if behavior changes its a heap corruption

calm latch
#

What could cause it though

fiery turtle
#

who knows, could be a bug in your kernel_api impl, could be a bug in the kernel's vmm handing out the same phys page for allocator storage

#

anything

#

u use an existing malloc impl right

calm latch
#

dlmalloc

fiery turtle
#

Ye

calm latch
#

I've recently changed how tlb shootdowns are handled, and that might have changed something in my vmm and I think it's been a bit fishy

fiery turtle
#

The only path through which this doesnt call map is when a table already has alive references

#

Which is impossible in this case

calm latch
#

Can I print references?

fiery turtle
#

Yeah ofc

#

table_ref_unlocked

calm latch
#

But tomorrow

fiery turtle
#

U can add a printf

fiery turtle
calm latch
#

I can try 32 bit userspace trl

fiery turtle
#

Try it

calm latch
#

The strange thing is that it's consistent

#

Or maybe not strange

#

No, it is strange

#

Printfs should have changed the order of stuff

fiery turtle
#

Well I mean its not multithreaded so why would it change

calm latch
#

The kernel is multithreaded

#

It's running 33 threads

fiery turtle
#

Which printfs do you mean

calm latch
#

On 16 threads CPU

#

Of allocs

#

They do IPC and stuff, which is slow

fiery turtle
#

Ah

#

Anyways im off to bed but happy to assist with debugging tomorrow

calm latch
#

Like if the pages get stolen and double mapped or something

#

Yeah it's 2 am where I live

fiery turtle
#

Memory corruption is evil

#

Gn

calm latch
#

Gn

calm latch
#

Ok I think I've fixed invariant tsc

#

My CPUID function was broken...

calm latch
#
    u32 ticks   = apic_read_reg(APIC_REG_TMRCURRCNT);
    u64 divisor = 1'000'000;

    apic_freq = computeFreqFraction(ticks, divisor)
    auto l = apic_freq*1'000'000'000;

    printf("%li %li\n", l, ticks*1000);

prints 4294339902999 3667574296

#

(and 3667574296 should be correct I think)

gentle peak
#

the apic timer counts down so you have to subtract the read value from your starting value

calm latch
#

I reset It in the beginning

gentle peak
#

yes but it still counts down

#

when you read it, you get the ticks remaining

#

that calculation needs the ticks elapsed so you need to subtract from the starting value

calm latch
#

So -1

calm latch
#

Thx

#

I think I have TSC

#

Can it take 0ms?

#

@fiery turtle

gentle peak
# calm latch So -1

what do you write to ICR when you start the timer? the value you want is icr - ccr

calm latch
#

I write -1, start the timer, and read its value

gentle peak
#

ok yeah then it's UINT32_MAX - value_read_from_timer

calm latch
#

So - what I've read should be number of ticks

#

Yes

#

Maybe I'm missing +1

#

Or -1

#

Anyway it's 662379999 662380000

#

And I'm using PIT for calibration...

#

So it probably doesn't matter

calm latch
#

Does this mean I have SEVERE heap corruption?

#

(and power button didn't work sadmeme)

calm latch
#

Could ACPI stuff be in bootloader reclaimable memory?

#

(LIMINE_MEMMAP_BOOTLOADER_RECLAIMABLE)

loud ice
#

probably not tho

#

not with limine anyway

calm latch
#

Because I'm reclaiming that

#

Started to recently

fiery turtle
#

you're corrupting internal uacpi structures

#

that are on the heap

calm latch
#

But that's weird

fiery turtle
#

managarm has an example

calm latch
#

My printf has been leaking memory and maybe that was masking it

#

(don't ask how)

fiery turtle
#

bruh

calm latch
#

Some quality code

#

I need to try static analyzers

#

Or dynamic ones

#

Although the only thing that should be allocating in between uACPI initialization is my PCI routing stuff...

calm latch
#

I don't know how that came to be

#

I need to stop using copilot

fiery turtle
#

indeed

fiery turtle
#

they didnt account for osses without an EC driver

#

so if EC is not available it uses uninitialized variables

#

not critical but yeah

#

firmware dev brain rot

calm latch
#

Does it calloc entries?

#

Because .data gets cleared by elf

#

By heap doesn't

fiery turtle
#
If (ECAV)
{
    If ((Acquire (LFCM, 0xA000) == 0x00))
    {
        Local0 = BA1P /* \_SB_.PCI0.LPC0.EC0_.BA1P */
        Release (LFCM)
    }
}

If ((Local0 & 0x01))
{
    Return (0x1F)
}

It initializes Local0 only if ECAV, which is EC availablility

fiery turtle
calm latch
#

And clears them?

fiery turtle
#

lets see

#

waiiiiiiiiiiiiiiiiit

#

waiiiiiiiit

#

might be a uacpi skill issue

#

can u revert table array len

#

and test one thing

calm latch
#

Yes

#

One second

#

How was it called?

#

Ok UACPI_STATIC_TABLE_ARRAY_LEN

fiery turtle
#

ye

calm latch
#

I reverted it

#

And I need to change malloc to calloc?

fiery turtle
#

no

#

one sec

calm latch
#

I've switched to git submodule btw

fiery turtle
#
diff --git a/source/tables.c b/source/tables.c
index 7e8de51..a30b070 100644
--- a/source/tables.c
+++ b/source/tables.c
@@ -563,6 +563,7 @@ static uacpi_status verify_and_install_table(
     dump_table_header(phys_addr, hdr);

     uacpi_memcpy(&table->hdr, hdr, sizeof(*hdr));
+    table->reference_count = 0;
     table->phys_addr = phys_addr;
     table->ptr = virt_addr;
     table->flags = flags;
@@ -571,7 +572,7 @@ static uacpi_status verify_and_install_table(
     if (out_table == UACPI_NULL)
         return UACPI_STATUS_OK;

-    table->reference_count = 1;
+    table->reference_count++;
#

idk why i even bother running ubsan and asan

#

they dont catch shit

calm latch
#

One sec I need to google how to apply patch

fiery turtle
#

lol

#

just do it by hand

#

its 2 lines of code

#

green is new stuff red is removed stuff

calm latch
#

Ok

hollow elm
hollow elm
fiery turtle
hollow elm
#

yeah

#

it's glibc-specific but it causes malloc to fill all fresh bytes with the given value

#

in this case 0xaa

fiery turtle
#

hmm are u sure thats the name?

calm latch
fiery turtle
#

0ms is possible yes, but you're getting 5 million a second

#

thats highly questionable

hollow elm
# fiery turtle hmm are u sure thats the name?
       M_PERTURB (since glibc 2.4)
              If  this  parameter  is  set to a nonzero value, then bytes of allocated memory (other than allocations via calloc(3)) are initialized to the complement of the value in the least significant byte of value, and when allocated
              memory is released using free(3), the freed bytes are set to the least significant byte of value.  This can be useful for detecting errors where programs incorrectly rely on allocated memory being  initialized  to  zero,  or
              reuse values in memory that has already been freed.

   Environment variables
...
       MALLOC_PERTURB_
              Controls the same parameter as mallopt() M_PERTURB.
calm latch
#

I have SSE in userspace πŸ‘‰ πŸ‘ˆ

hollow elm
#

man 3 mallopt

#

i did get the values wrong

#

it's ~0xaa when mallocing, then 0xaa after freeing

fiery turtle
#

doesnt repro for some reason

#

with that variable

calm latch
#

Ok I'm trying it

fiery turtle
#
❯ MALLOC_PERTURB_=170 /mnt/d/uacpi/tests/runner/build-linux-64bits/test-runner dsdt.dat -x ssdt1.dat ssdt2.dat ssdt3.dat ssdt4.dat ssdt5.dat ssdt6.dat ssdt7.dat ssdt8.dat ssdt9.dat ssdt10.dat ssdt11.dat ssdt12.dat ssdt13.dat ssdt14.dat ssdt15.dat ssdt16.dat ssdt17.dat ssdt18.dat ssdt19.dat ssdt20.dat ssdt21.dat ssdt22.dat ssdt23.dat ssdt24.dat
calm latch
#

(I have to restart laptop (which is obnoxious with windows 11 for some reason), disable secure boot, reboot it again so it sees my usb drive, and then do everything in reverse)

fiery turtle
#

thats painful

#

anyways 99% confidence its a uacpi bug so i feel dumb

fiery turtle
#

sure but u get like a 3.5x speedup vs fastest kernel here

#

so idk

calm latch
#

Though the new time source is like 60% probability broken

#

Why does it always boot windows

fiery turtle
#

these types of bugs are why most linux distros ship with unconditional zeroing of absolutely all allocated memory

#

(in the kernel i mean)

vast kestrel
#

Yeah kernel devs just forget

#

In our embedded code we just define malloc to zero to not have a chance to forget to zero

calm latch
#

I like to live dangerously, my kernel doesn't

#

(and userspace as well)

fiery turtle
#

best bet for production

calm latch
#

It worked

vast kestrel
#

Speed

fiery turtle
#

thanks for testing

#

sorry i blamed u

#

still cant repro this bug locally somehow

calm latch
#

😎

fiery turtle
#

that avg is insane if true, but i doubt it tbh

calm latch
#

I'm gonna check get_nanoseconds_since_boot() against sleep

#

Which is definitely working and uses lapic

fiery turtle
#

like even the log spam above it

#

takes way longer than 1ms

calm latch
#

Why would it

#

It's asynchronous

fiery turtle
#

oh then maybe not

#
--- a/tests/runner/interface_impl.cpp
+++ b/tests/runner/interface_impl.cpp
@@ -228,6 +228,8 @@ void* uacpi_kernel_alloc(uacpi_size size)
         return ret;

     allocations[ret] = size;
+    memset(ret, 0xFF, size);
+
     ret
#

i did this

#

but still not repo

#

repro

#

idk

calm latch
#

With my laptop's tables?

#

Idk

fiery turtle
#

it should work with any tables as long as there's more than static array len

calm latch
#

Could it be a particular case when the pointer is null but the rest isn't?

fiery turtle
#

ohhh wait yes

#

im retarded

calm latch
#

Ok it booted back...

fiery turtle
#

or actually no

#

bogus pointer value should segfault

calm latch
#

Where does out table come from?

#

Ok I'm gonna remove the prints just to be extra sure

#

That I didn't boot an old iso or something

#

And also check nanoseconds stuff

fiery turtle
#

ohhhh

#

its because i was using early_table_access

#

so my structures are copied from there on init

#
    static uint8_t early_table_buf[4096];
    auto st = uacpi_setup_early_table_access(
        early_table_buf, sizeof(early_table_buf)
    );
    ensure_ok_status(st);
#

this stuff hid the bug

#
/mnt/d/uACPI/source/interpreter.c:1259:23: runtime error: member access within null pointer of type 'struct acpi_dsdt'
/mnt/d/uACPI/source/interpreter.c:1260:32: runtime error: member access within null pointer of type 'struct acpi_dsdt'
AddressSanitizer:DEADLYSIGNAL
=================================================================
==1189==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000004 (pc 0x55bd8f039a97 bp 0x7ffc4f2720f0 sp 0x7ffc4f2720a0 T0)
==1189==The signal is caused by a READ memory access.
==1189==Hint: address points to the zero page.
    #0 0x55bd8f039a97 in prepare_table_load /mnt/d/uACPI/source/interpreter.c:1260
    #1 0x55bd8f039d04 in do_load_table /mnt/d/uACPI/source/interpreter.c:1272
    #2 0x55bd8f03cb19 in uacpi_execute_table /mnt/d/uACPI/source/interpreter.c:1539
    #3 0x55bd8f00c2a1 in uacpi_table_load_with_cause /mnt/d/uACPI/source/tables.c:1088
    #4 0x55bd8f01b4e5 in uacpi_namespace_load /mnt/d/uACPI/source/uacpi.c:395
    #5 0x55bd8ef6577a in run_test /mnt/d/uACPI/tests/runner/test_runner.cpp:486
    #6 0x55bd8ef67b81 in main /mnt/d/uACPI/tests/runner/test_runner.cpp:622
    #7 0x7f7517df3d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #8 0x7f7517df3e3f in __libc_start_main_impl ../csu/libc-start.c:392
    #9 0x55bd8ef5f4e4 in _start (/mnt/d/uacpi/tests/runner/build-linux-64bits/test-runner+0x19d4e4)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /mnt/d/uACPI/source/interpreter.c:1260 in prepare_table_load
==1189==ABORTING
#

there u go

#

this is the crash u were seeing

#

yup verified that fix works

#

will push shortly

calm latch
#

The timer is broken

calm latch
#

Another bug found

#

which is not my fault