#uACPI - a portable and easy-to-integrate ACPI implementation
1 messages · Page 60 of 1
You still want stuff to be zeroed tho
When you do a read fault it maps the special zeroed page. When you write later, it does a COW fault to create a new writable page there whose contents are initialized by memcpying the zero page into it rather than memseting it to zero
usually when u allocate new memory u write to it first, not read it
so u wouldnt even reach that path in the handler
idk why you call it a cow fault, its not
theres no data to copy
It went through the COW path
it doesnt go through the cow path in the linux code at least
It would allocate a new page frame and copy the zeroed page into it and give you that
it goes through the standard anon page path
Lemme find the paper about this
No, I mean if you have a Page struct, how does it find where (in which processes) it's mapped?
page->mapping
if its a file page the mapping is actually a struct address_space aka a file
and that has a list of vm_areas mapping it
this is basically all there is
code below that is for write faults
I said past tense so this doesn't mean anything
ah ok
do u mean it would do a stupid thing of memcpying something that doesnt need to be copied?
.
well this aint past tense
ah ok
well
rn it seems more optimized
the cow path is very slow and does tons of stuff
But what if it's mapped into several processes?
ChatGPT says linux uses anon_vma
Chatgpt đ
did u just ignore this part lol
Yeah, idk if it can be trusted
During the stabilization phase of the kernel development cycle, the -rc releases typically happ [...]
I guess my kernel's design is less dumb than I expected
Here's my source: https://dl.acm.org/doi/pdf/10.1145/3291276.3291278
Good article doing a deep dive into the performance of running hello world on Linux (by the guy who designed the DEC Alpha!)
What if it's not a file mapping?
Touches on the memcpy of the zero page
(yeah, I can't read)
From 2018
Fairly recent ish
Also identifies a major performance issue with the idle loop
Putting the machine into a low power state too quickly
which caused undesirable scheduler behavior
No maybe the scheduler thing was another paper
Guy notices that the completely fair scheduler isn't fair at all and actually seems pseudorandom on short (for humans, ages for computers) time scales that it should be able to handle and it turns out to be because Linux's idle loop is going into a low power state too quickly, it doesn't spin for long enough first, and it takes so long to come back out of that state that the scheduler's responsiveness on that timescale is trashed and all of its policies are for naught. He complains that statistically it should spin for about half the time it takes to leave the low power state (which is on the scale of a millisecond iirc) and instead it was spinning for some arbitrary amount of time that was far too short, and when he changes it to do this the scheduling issues disappear. Very interesting stuff
I wanna say that was also Dick Sites but I don't know the name of the paper
then mapping just points to the vma of the process
cool
ill give that a read
thats in C???
I mean C also has constexpr now
but not in if no
how about a fs driver api? either at compile time or runtime
didnt that get removed
i feel like i asked this before, but i assume that uacpi expects uacpi_kernel_alloc to behave just like malloc, that is allocations must be aligned such that it can store an object of any type
in which case 16 byte alignment should do, at least for x86_64
it would also be nice if the kernel api comments mentioned that too :^)
mine doesn't guarantee any alignment atm đŹ
i mean sure but like
if your malloc generates a smaller alignment its ub anyway
so idk if such things should be mentioned
like it doesnt have any special requirements on top of the C standard
i just ask the allocator for 16-byte aligned blocks
that covers all important types
i do too, i just call alignedAlloc with alignment: .@â16â
i just need to implement a page allocator now zzz
Today I'm adding uACPI
i have no idea if i do
i just give it the address kmalloc returns
and that either returns a vmm region base or a slab obj base
i think it should be 64 byte aligned
depends on the abi tho
anpther todo
i think C requires 16-byte alignment in sysv
c++ is 64 byte i think
malloc
malloc isn't sysv tho?
alignof(max_align_t)
posix maybe
which should be 16
max_align_t yeah
on most platforms (x86_64)
like my kernel doesn't adhere to anything posix internally
well stack is one thing
whats the diff tho
why would stack and malloc have different alignments
idk why either have alignment
what
because they store multi byte types
are u trolling or serious lol
u realize there is hardware which can't do unaligned read/writes right
for example that is a good reason to have aligned addresses
I'm not saying there isnt
the standard isn't an x86 standard
ill just do an assert to check if kmalloc returns a non aligned addr
misaligned atomics segfault on linux by default
I'm aware
the generic sysv doesn't define an alignment tho no?
stack alignment is part of the abi
sysv
there are diff sysv for diff platforms
each has a stack alignment
sure does
it does not define any alignment for malloc though, because it doesn't define malloc
yes, thats posix/c standard
yes
RETURN VALUE
The malloc(), calloc(), realloc(), and reallocarray() functions
return a pointer to the allocated memory, which is suitably
aligned for any type that fits into the requested size or less.```
SSE:
don't think it counts as perf when the instruction throws an exception when misaligned
also xsave throws an exception when not 64 byte aligned
yes but u don't give it na unaligned address
no shit
the compiler gives it an offset from some stack address
which it assumes is aligned
bro what the fuck are we even talking about
but posix does
sysv defines that some types have 16 byte alignment, and iso c defines that malloc returns an area with suitable alignment for any type that fits, therefore sysv defines that malloc returns an area aligned to 16 bytes if you request >=16 bytes
technically if u do a 1 byte allocation it can return a 1-byte aligned address right
okay so funny thing
yea
although idk if anyone has a special object storage for it
slab allocation in nyaux is not 16 byte aligned
how did u even manage to misalign a slab
its 8 byte aligned tho
for uacpi?
uacpi doesnt use any double/float etc
oh
so it can survive 8 byte aligned malloc
although if u enable SSE and compile it for userspace the compiler might use SSE to zero stuff etc
also, malloc aligning to 8 instead of 16 only matters in two cases:
- someone uses it with a type that actually has a >8 byte alignment
- the compiler recognizes it as malloc
ye
i was thinking maybe if it implicitly used SSE it would assume 16-byte alignment
if you compile with -ffreestanding or don't call it malloc, it won't
true
i call it kmalloc so it SHOULD be fine
afterall userspace will take shit from vmm region allocated shit anyway, that makes sure its aligned to at least a page
SSE: 
nice round number
KittyOS
AMD Ryzen 5 2600 but wait till I put it on GitHub
other sources are meh
My timer fires each 0.5ms
if you go fast enough you will probably get an imprecise timer warning
how fast is too fast?
what's the limit on qemu with 1740 ops?
that's how you win uacpi
Real
i love uACPI
Insert uacpi heart locket
infy, go make it
I love how this turned into a competition
competition in to who gets the most points
yes
uacpi my beloved
uacpi logo when
sniped
add some logo
@fiery turtle add when
nah it's pretty average
I'd say bigger than average
acpi.sys is average
idk if you got my joke or not
I did

im a pro artist i know
And this? 3 scores, but 2 configs.
1st score - q35 no kvm O0
2nd score - q35 kvm O0
3rd score - q35 kvm O3
its mine license
The difference is desperate.
I'm just analyzing, why do you see "problem".
pro
when nyaux will cost a lot of money i will remember this license
Isn't 0.5ms too coarse?
When the whole thing takes like a ms yeah
1740 * 2000 = 3480000
Petition to only allow kvm timer measurements in the leaderboard 
I can tune it to be 5x more accurate if ya want
or ykw, i want.
Tbh you have a point, with how little time the benchmark takes only hpet tsc and TSC derived are really precise enough
I use PIT :( (to calibrate)
but LAPIC timer is being used
i can implement HPET if ya waant people
As calibration pit's fine
others told me PIT is bad and inaccurate..
When used properly the pit has a resolution of ~0.8us iirc, which is plenty for calibration
Where "used properly" means reading the current value from the timer, not just counting interrupts
The reason you don't want to rely on it for calibration is that it's both not guaranteed to be available and unenumerable
Which means that you're blindly poking IO ports you aren't sure of the meaning of
So a common strategy is to only touch the pit (this includes initializing it) if you need to calibrate apic timer and/or TSC (aka their frequencies aren't in cpuid) and no enumerable timers (hpet, acpi pm timer, etc) are available
Aka it's a last resort
Define âfineâ, HPET is very simple to just hack to get calibration.
Oh ok nvm you explained the limitations
@fiery turtle What do I need to do to get on the leaderboard of AML parsing?
See gh issue
Okay
least lazy issue
close it 
close it as 'skill issue'
though i think their gh has the operating system
ah it's the LARP guy
Maybe you should add an issue template
Yeah
lol do you say LARP because their code is very "wannabe-esque"
The Hyra operating system. Mirror of https://osmora.org/cgit/Hyra/ - Pull requests not accepted, send patches to [email protected] - sigsegv7/Hyra
mostly stubbed out or wrong kernel api implementation
still makes an issue before debugging
really bad bsd larp
that kernel
it only takes me like 60 seconds of perusal to tell whether something sucks now
yeah it does look like discount bsd
some of it is plagiarized
did a double take when this had an ifdef for fucking dec alpha
ah
still lame to copypaste an allocator instead of doing their own
especially when the rest of the kernel is so anemic
yeah thats like
doesnt even have blocking mutexes
literally returns a spinlock for uacpi mutexes
maybe they should steal a mutex impl from somewhere
4x as many stars as mintia2 btw
(ill forever bitch about people who posted their thing once (1 time) on hackernews having more stars than me instead of just advertising myself, because bitching is more fun)
https://github.com/sigsegv7/Hyra/blob/10d42916f7888bfdefce401dc0b0eccd26a5ec69/sys/dev/acpi/uacpi.c#L181 preeety sure that's incorrect
lmfao
yeees... that's totally how spinlocks work...
except for the part where you don't spin
i sometimes wish i was as oblivious as this guy
not a worry in the world
who needs a spinlock when you can just lock instead
save some cpu cycles, just don't spin 
guy kept up at night by a slight performance issue suddenly realized at 1am vs guy who spams his os project all over hackernews without knowing what a spinlock is
just let multiple CPUs enter the critical section without even disabling interrupts, I'm sure it'll be fine
jesus
if (timeout == 0xFFFF) {
while (*counter != 0) {
md_pause();
}
return UACPI_TRUE;
}```
what?
oh god nevermind i misread that
my blood pressure is rising
STOP talking about bad osdev ill aneurysm
i should start an anonymous blog called "bad osdev" where i just rip apart overrated bad projects with immense cruelty
what is md_pause supposed to do
good question, but according to the comment on that macro it emits F390 which is supposed to be pause
which it does emit
yeah it actually assembles to f390
and so does pause
apparently pause is just rep nop
funny
it feels like something a 60 year old programmer would do
except they are definitely not 60 years old
it seems like something done to be compatible with older assemblers that werent aware of the pause instruction that this person blindly copied from a bsd header file somewhere 15 years after it stopped being necessary
it has the vibe of being stolen from a codebase where it was introduced prior to assembler support
fuck
i wanted to give them some benefit of the doubt
but that is the most likely explanation
i mean even in your explanation that would be the reason
the 60 year old would do that by reflex because in his mind if he doesnt the assembler is gonna error out because he hasnt thought about it since 2010
yeah but the 60 year old guy didn't copy paste it from some other project :^)
i dont actually know how old pause is in x86 im just guessing its weirdly late like pcids
maybe its from 1998 idk
SSE?
it was introduced with sse2
So like quite old
year 2000
It's older than me
same lmao
yeah pause is just a fancy mnemonic for rep nop
Yes and he was here before and is a major LARPer with his org and stuff
*use
use what
i meant to say "doesn't use pause"
@fiery turtle in terms of API/ABI/bindings, the only difference between 2.x and 3.x is that the misspelled UACPI_POISITIVE_DECODE macro was removed?
the static assert macro was moved to the platform headers
is that all?
yes
alright, ty
np
wasn't there also a field that was renamed?
because it was a watcom keyword before or something
thats an internal struct luckily
wait really? because it's not in the internal dir
where u at in deltarune lol
still doing jevil, went to sleep in the middle of it yesterday
fair lol
ah fuck
i forgot about that one
should add it to the changelog
yeahhhh
damn uacpi is dead
micro optimizations when :p
after the kernel is done 
How is uACPI kernel doing? 
Jit when :^)
When you implement it 
not really
i'd say some software just stops being as active once it nears completion
which is a good thing
fair
i have some ideas for 3.1
optional mmio helpers, some new suggested api
not sure when ill get around to that
3.1 For Workgroups
corporate uacpi
3.1 introduces the uACPI executive and the uACPI proper
any details on these? im curious
suggested api by mint for subtable iteration and there was something else iirc
Mmio helpers is just optional kernel functions for accessing memory like io ports currently work
ah ok
doesnt that go through map anyway? or is this for when you want to use the hhdm or something
I think it's for fences
or when u have special rules for accessing mmio, like EAX on amd
Wait RTC is a namespace in ACPI? https://elixir.bootlin.com/linux/v6.15.4/source/drivers/acpi/x86/cmos_rtc.c
Or CMOS*
u mean address space
yeah
it is
not sure tbh
I can try implementing it for fun
like wtf???
who knows
lemme grep
firmware devs
also infy u saw my laptops AML dump before right
wasnt something with it really cancerous
i dont remember
probably lol
114 out of 500

This week I encountered hardware that has multiple host bridges with the only way to find all of them being acpi 
Note not multiple domains, but multiple host bridges under the same domain
The MCFG had the entire domain, but you can't find all devices using the normal iteration starting at 0:0.0
Mine is a Skylake-E server
Will see if I can 
nice
Look at this thing
Iâm going to go grab one and dump the tables
That is one cursed CPU
mfw the machine's MADT LAPIC entry is non-existent 
I just bought the first thing I saw with CPU idk what it is
In line rn
I just bought and didnât look at it
It was 100$
Itâs an AIO
how many computers do you own now
lol
5 cores lol
i bet its laggy af
It is⊠awful
its one of those computers u make poeple use as a torture method
Don't give them ideas
thats literally what it says in that link
1 p core 4 ecores
lmaoooooo i didnt even look at it đ
and that p core is hyper threaded????
what
1p 4e exists
it's called Lakefield
(yes the P-core is hyperthreaded)
L field
oh right i forgot to send a dump of the dual cpu machine
doing that when im home
though this one is RPL
i did not know/remember even that there were RPL SKUs that were 1P/4E lol
Yeah this thing is funny
I have B450M-S2H motherboard witrh AMD Ryzen 5 2600 if u want the dump too
yeah if you could PR it in the repo that'd be great
example pr https://github.com/uACPI/ACPIDumps/pull/4
wifi would be interesting
do those have extra acpi stuff
i have no idea how wifi works
i think via pcie
lemme go grab that dump
hmm, it says it has uploaded the dump
how do i download it?
after some optimizations, Ironclad is scores like this
(0000000001) successfully loaded 1 AML blob, 1708 ops in 0ms (avg 6196937/s)
I claim a deserved bump in the results ahead of managarm once more
was not aware there was such a mechanism, ill do so, thanks
yeah i made it so that i dont forget anything and have everything centralized
makes sense, good decision
In file included from uACPI/include/uacpi/internal/compiler.h:3:0,
from uACPI/include/uacpi/status.h:3,
from uACPI/include/uacpi/types.h:3,
from uACPI/include/uacpi/kernel_api.h:3,
from src/acpi.c:6:
uACPI/include/uacpi/platform/compiler.h:43:24: error: missing binary operator before token "("
#if __has_attribute(__fallthrough__)
^
GNUmakefile:190: recipe for target 'obj-x86_64/src/acpi.c.o' failed``` @fiery turtle
this happens with gcc 4.9.2
... don't ask
if you support openwatcom you should support this too
uhh, it has no __has_attribute?
i'd assume so
/* fallthrough */ time
does it?
uh i am using gcc 4 because i am testing whether stuff builds on old Debian versions
even on msvc?
i mean on gcc
gcc has a great function to detect fallthrough comments
does it emit a warning if u no-op it on that version? @lofty dragon
it doesn't appear to i don't think
ok cool
like u have to initialize literally every field?
i assume so? i still wouldn't bother, really
it's an old gcc
as long as it builds i'd call it fine
yeah i think thats the way
@fiery turtle u gonna fix it now?
@torpid ferry i saw you type btw
you can't hide
i mean yes, do u need it like urgently or something
well
not urgently but if you tell me whether i should wait for it or move on, i'd appreciate it lol
ill fix it by today evening
u said u needed it for testing right
with that stuff fixed it compiles
why do u need it in master rn?
well i depend on it as a submodule in csmwrap, but as i said
i don't need it right now
it's more of an "i am an impatient bitch" kind of situation
ADHD or whatever
of course :3
@lofty dragon can u check if this is enough
- #if __has_attribute(__fallthrough__)
+ #if defined(__has_attribute) && __has_attribute(__fallthrough__)
sure
nah
it doesn't work still
uACPI/include/uacpi/platform/compiler.h:43:52: error: missing binary operator before token "("
#if defined(__has_attribute) && __has_attribute(__fallthrough__)```
fuck
you may have to put it on a separate line
yep
yeah it works on a separate line
- #if __has_attribute(__fallthrough__)
- #define UACPI_FALLTHROUGH __attribute__((__fallthrough__))
+ #ifdef __has_attribute
+ #if __has_attribute(__fallthrough__)
+ #define UACPI_FALLTHROUGH __attribute__((__fallthrough__))
+ #endif
#endif
Can u try this
i already did, of course :3
ok cool, im just gonna push it then
LGTM
pushed
tysm!
np!
added new _PIC values from spec 6.6, some risc-v stuff etc
infy get ready to update leaderboards đ
Yes but submit it to the issue on gh
k
Nice
pretty cool
for future reference why ACPI PCI hotplug is better than native
at least in VMs although some of these apply to real hw as well I guess
not really since on real hw the acpi impl still has to follow the acpi spec
not sure if acpi hotplug is even supported on real hw
hm?
not really its not better for VMs because it has to follow the acpi spec on real hw?
not sure i understood that sentence
pcie spec is kinda irrelevant here because the firmware will simply refuse to give platform control over native hotplug
so you will have to use acpi hotplug
in qemu at least
in dmesg | grep acpi it should mention whether it got native pcie hotplug control
no, the firmware still has to follow the AttnBtn requirements
probably possible via sysfs but idk how
no, i mean for a specific pcie bridge
probably, but idk the file to look at
probably echo "eject" somewhere which will call some hotplug ops which will call _EJ0 on the device
its abstracted away in sysfs most likely
will just call into whatever thing is used to control hotplug
ah it uses the same file as pcie hot unplug
yeah
anyway in vms it allows to circumvent all of that real hw emulation stuff and just do the thing fast
i remember that we had some issues with acpi hotplug on real hw
but idr what the issues were
thats possible considering it requires well written firmware
fun fact on AWS bare metal you have to support hotplug because their pcie adds most devices at runtime
how does that even work, are they like physically inserted or what lol?
i think they have a custom pcie bus that virtualizes the actual devices
even when running on bare metal
well written and firmware, what an oxymoron
real
qemu's firmware is relatively decent at least 
tbh all it has to do is access some qemu specific registers and propagate that to the host os
but it works well ig
graviton?
seconded
Qwinci what are you up to these days
we moved a few weeks ago and after that I haven't really worked on anything (except the civil service job that I had, though it ended last week), I should get back to working on something again as in the past few days I have mostly just been playing stupid mobile games lol (though I still don't have very good internet as the fiber that the building has doesn't work for some reason and is not yet fixed + mobile network connection inside the building is at times so bad that opening websites takes ages)
Thats cool
it has a BMC lol
A what?
a management chip
so you can start the machine via ipmi or web ui
something that most servers have
ah
but cool to see they do something to be more compliant with uefi
I haven't found where you can order the BMC module yet
might be a thing for the futureâą
I didn't expect an ACPI capable board to show up that quickly
considering that the ACPI pieces for rv were only ratifies a month ago
so they must have been cooking this already based on the draft specs
well that's just firmware
the soc is a bit older
and it only releases in like 3 months
Do you have a pre release copy
have? no. will get one? probably
but they say on the store site that it's estimated to release in 90 days
Leak its aml 
i do wonder if it'll be as good as the orion o6 aml
Inb4 lazy dt converted to aml aml

well, realistically you also need hw support though
see the rpi4
fair enough
where compliant acpi is impossible
even though people invested considerable effort
Maybe it was designed with proper ecam etc in mind
Oh snap, amazing
I kinda want one
@fiery turtle im trying to find a way to generalize both PCI vendor/family info and PNP driver identifiers as to generalize a device bus for both. Is there a way to get that data from ACPI PNP?
or do I need to have a software array to convert them the ugliest way possible
those are separate things
PNP devices are not PCI devices
PCI devices have _ADR, non-pci devices have _HID
so i would have those be unrelated busses
well that fucking sucks
lol
well the parent PCI bus will have a _BBN/_SEG and the PNP ID telling u its a pci bus
everything underneath will not have _HID
but only _ADR to tell u where its located on the bus
so I can have 2 buses, devices publish themselves on both, and have some architectures opt out of having some buses? thats a mess
but I mean
idk how else I can abstract it
realistically all architectures have both pci and acpi
and i dont see collisions there tbh
devices that advertise themselves as part of the acpi device tree are not discoverable otherwise
and I can check for PCI regardless of architecture with the MCFG table ig
if Im going to hard depend on ACPI for stuff like that though I could just not touch PCI whatsoever
because all PCI devices are advertised on ACPI right?
only the root busses
and some children that need extra information
for example usb-specific stuff or HDA etc
so I can treat PCI as a driver-bus
like a USB bridge would be
that makes more sense
basically you have
- ACPI BUS
- PCI ROOT 0x00
- PCI CHILDREN
- PCI ROOT 0x80
- PCI CHILDREN
- PS/2 Keyboard
- EC
- PCI ROOT 0x00
PCI children have the root as parent
and the root has acpi as parent
so yeah I really only need 1 bus, and treat PCI like a USB bus would be instead of a completely separate bus
I like that idea that is a way cleaner approach than the 2 separate buses
thank you my dear infy
np lol
oh thats neat
Arm can have systems without PCI
They arenât very common anymore, but they existed for about 10 years
RT, Lumias, all donât have PCI yet have ACPI uefi
Another thing different from a common x86. say, with the current rockchip flagship soc rk3588. do xhci, ahci etc controllers sit on pcie? nope. They sit on ahb, apb, i believe. pcie is just another peripheral here. And often too deviant (doesn't work as should).
yeah i meant more like the arch in general works with pci, some devices dont have it obv
ARM SBCs having weird controllers on non-standard busses for (usually) tame, standardized stuff is not surprising
same for RISC-V really
Certainly not all hw fits into acpis hardware model
some stuff just cannot be represented
in ACPI tables and/or the namespace
BTW PSA about using the HHDM for uacpi_kernel_map, this should only by used for when AML is mapping normal system RAM
if it's mapping anything else you should really allocate and map it separately with appropriate cache attributes
also mapping anything other than normal system RAM in the HHDM might break as well even without uacpi
if you want your hhdm to work on all cpus you must carefully carve out and map only stuff reported as normal ram there
Even though the kernel never
generates memory accesses in that region, since the page tables mark
them incorrectly as being WB, our (AMD) processor ends up causing a MCE
while doing some memory bookkeeping/optimizations around that area.
I already posted this before but ig it's worth a separate PSA
this is a problem only for mappings above 4G which arent covered by MTRRs
it's unlikely to see aml do that but still possible
thanks for posting this, good to know
yeah thought i would try to raise awareness about the dangers of HHDM 
I will place a TODO in my code and do nothing else about this 
lol, are you anti-hhdm now?
presumably this breaks on some AMD CPUs, but idk which ones specifically
same as EAX for MMIO lol
nah lol
Does limine automatically handle this?
i think limine only maps usable ram in the hhdm so yeah
on higher protocol revisions, yeah
I think for revision 0 it tries to greedily map the first 4G
first 4G u can safely map as WB so thats fine
oh nice
after that you must either manually configure MTRRs for all non-ram ranges or map those as UC in your HHDM
i might do the latter, not sure
just have HHDM map everything up to max page, but carefully setting UC for everything thats non-ram
can you just leave those ranges unmapped?
thats what linux does for example
ah perfect, thats what I was going to do
and then for mapping e.g. BARs it uses ioremap
which just vmallocs some virtual memory and then maps as UC
yeah makes sense
above 4G decoding was a mistake
well without it we wouldnt have optimized GPU mem access via BAR apertures etc
it's just MTRRs are kinda inflexible and suck
Lol i first thought there is no way that linux maps non-ram into its direct map
Because that's quite stupid
But the post is from 2012
yeah it used to do it for a very long time
Although the reasoning in the commit doesn't apply anymore
it would just compute max pfn and map up to that
Mtrrs now usually cover the entire address space correctly
any source for that?
just from my personal experience
did u dump MTRRs or how do u know
yes
just for fun?
I debugged a few MTRR issues in the past
but even if they are set up correctly there can be issues with non-RAM in a direct map
hm okay
for example if there is stolen memory
that must not be accessed as WB
i'm not sure if that is always properly respected by MTRRs everywhere
and that also applies below 4G
i remember doing some igpu things
and accessing stolen memory would triple fault on one laptop
and hang on other
fun times
did you have a double fault handler?
yeah, i'd expect it to go into an MCE
i should recheck with a proper idt
it's documented that you must not access stolen memory as RAM though
yeah
and then access via the bar aperture
there are also other devices that can steal memory via uefi
like what?
id assume it would just reserve some ram and then mark it as RESERVED
like it doesnt have to MCE you
and proprietary devices that use it in place of on chip RAM
i know that some RAID controllers do that
raid controllers are crazy
there isnt a standard for them iirc
its just all proprietary stuff
yeah, it certainly won't show up as RAM in the address map. but the question is: does it also update MTRRs to mark that range as UC? not sure
if you only map RAM, you should be safe
yeah
well you definitely shouldnt rely on MTRRs for that sort of stuff thats for sure
just map it as UC etc
you can basically assume that OS-usable RAM is marked as WB in MTRRs and you can assume that MMIO is marked as UC
if one of these is not true, the system probably won't work anyway
but you probably shouldn't assume anything about non-RAM non-device regions
well judging by that commit from 2012 u clearly cannot assume that
maybe on more recent hw
it's possible to have less MTRRs than decodable MMIO ranges for example probably
or just crappy firmware that either forgets to configure MTRRs, or doesnt touch anything above 4G etc
like i doubt they would even notice because linux/windows dont rely on that anyway
that's very unlikely
i doubt that, never seen it happen in practice except in weird situations (in which case this was fixed in firmware after reporting it)
i mean yeah ofc it's probably fixed, but you would still have tons of users on the old firmware version
only talking about (the OS-usable RAM || MMIO range) cases here
and it boots windows just fine probably
IÂ assume this is the TGL+ GPU page tables meme?
if these are set up incorrectly, then non-PAT accesses would be broken
for example in real mode or SMM
which you'd generally notice
u think SMM ever touches BARs?
iirc they specifically try to avoid that by doing everything via the config space
which is fixed offset and under 4G
just checked my laptop and it certainly has > 4G ranges set up correctly
i believe you
what about under 4G?
It has another 2G + 256M + 64M as UC below 4G
IOW there are at most 1.7G usable RAM below 4G 
yeah modern hw kinda leaves very little ram there lol
what's even the minimum that you need
probably RAM in the first 1M
would be enough to make modern systems happy
yeah probably like 100M in the low range
do you even need any RAM between 1M and 4G?
you need RAM below 1M, otherwise you can't boot APs
if u do UEFI only probably not
latest intel is uefi only anyway
you still need some ram to be able to change paging modes etc
since u have to drop down to pm
uefi technically has a way to boot APs directly to long mode
idk if anything implements it
who knows maybe they could invent a proprietary shortcut for that
its easier to just leave some ram under 4G lol
hm true yeah i dont think theres even anything in the spec to avoid real mode there
they could invent uefi runtime services for it
if they really wanted to
i doubt that intel will do that though
there's no reason to yeah
they won't make their CPU arch dependent on uefi
maybe if they went with x86s etc
if anything, they'd add a mechanism in the CPU that can be used by uefi to implement this service
well ram configuration is kinda not really dictated by the arch anyway
only the lower 1m i guess in case of x86
there are a few more addresses that are architecturally defined
for example the reset vector
and the MSI range
ah
ah wait no for 386, it's 4G - 16 and the CPU is essentially in unreal mode when it boots
damn lol
ehh it's very different from unreal mode
unreal mode is where the limit is 4G instead of 64K while still in real mode, at reset the limits are all still 64K the cs base is just 0xffff0000 instead of 0xf0000 like the selector would suggest
yeah true
I've had to deal with this cuz I wrote a x86 emulator :3
0xFFFF:0x0000 is the 8086 reset vector
0xF000:0xFFF0 is the 286 reset vector but CS base is 0xFF0000
i haven't encountered any software that depends on exactly this but seemingly most BIOSes do a far jump to normalise the CS to these values (0xFFFF on 8086 and 0xF000 on 286 and later BIOSes)
nope it's more like, CS base moves that to the end of the 4G for 386 and later, and to the end of the 16M for 286
so the physical address is 4G - 16 (or 16M - 16) but real mode software thinks it's 1M - 16
But a far jump would reload the segement base, so you'd always end up below 1M, no?
hmm I didn't think about that
well ROM shadowing was starting to be a thing back then
so probably?
strange that they didnt added 32/64bit sipi's
there was a proposal for a startup mechanism that entered to long mode as part of x86s, one of them few good things in there
same with being able to change the number of paging levels without leaving long mode
first batch
i mean like when 32bit/64bit mode were added, missed opertunity like not adding cmpxgch16b with amd64 from the start
from what version
2.(last)
are you sure it isn't an issue on your end that got introduced after the last time you tried?
no i didn't change anything
i'll revert hold on
this is super weird
i didn't change anything acpi related
2.1.1 doesnt work either
any chance u have smm disabled
i dont think so
this is on qemu right
then yeah just git bisect is your friend
my dumass changed pic code and forgot to unmask the event interrupt
I have built uACPI into my kernel
as in, it's compiling and linked
which took long enough
I do not have enough implemented for the kernel interface but will be soon
the issue is that I'm using rust and nix and vendoring-in uACPI sources really makes it rough cuz bindgen and cc-rs didn't like my build system
tho it's working nice now (I just copied the nixpkgs hook for bindgen)
Yeah maybe shinribo will eventually finish those bindings
that would be awesome yes
working on it, had little time because of studying
feeling bored, I'm gonna see if uACPI has dumps for all of my hardware, and submit it if you don't
ok so of my hardware, it looks like yall don't have:
- ASRock B450 Steel Legend
- ThinkPad T14 Gen 1 AMD
- Dell Optiplex 755
- Dell Optiplex 7040
- Dell Precision T1650
- Dell Latitude E5250
- Beelink SER (Ryzen 5 5500U)
- Beelink SER (Ryzen 5 5700U)
In fact that only overlap between what I own and what's in the repo is HP ProBook 4540s 
so I guess yall are getting several dumps in a minute here
got em all
i have one of those SERs too
I'AM FREE
Time to procrastinate for 12 weeks straight until next exam phase
pog
Nice
Lol
link to the wiki page?
yeah lol, got more dumps in one day than in that repo's history
well done!
at least looks like all of the new ones run fine
did adding a new ACPI dump catch anything so far
nothing so far
but even without catching bugs its useful for figuring out statistics of how various aml is used and whether certain stuff is used at all
if only it was still functional, I'd actually have one more that I could send off, an ASUS PRIME H610M-E D4
but sadly that thing died at some point, board just doesn't do anything when power button is pressed (no it's not an actual power button issue), PS_ON never gets shorted to ground
that one might have honestly been a more interesting one, since it's an ultra-budget board that really sucks in many ways
might've had crap AML
I also really wanted to send off some non-x86 devices but literally everything else I have is just DT, none have ACPI đ
what if u short it urself
I did try shorting the power button pins, it does the same thing (that's why I said "no it's not an actual power button issue")
if you mean short PS_ON and ground in the ATX connector, I also tried that
it draws like 18W, the fan starts spinning at max speed, and absolutely nothing of value happens
how much of AML is dynamically generated?
probs none?
is it possible to dump stuff from the flash directly then?
with a clip
possibly? I don't have an EEPROM reader
nor the money to buy one
(I have $0.59 to my name, with no income)
:(
I mean I could probably just extract it from the BIOS update file if it is static
but there's no garuantee that it really is static
I might to that too (when I'm back from vacation, ping me in 4 weeks)
Actually, I might dump my Thinkpad T590 today
but the code isn't right
it's basically some data tables or whatever that get filled in?
the code is also runtime generated
at least some of it
oof
especially anything that comes from devices like your gpu etc
right it's not just the motherboard
ye
You can use mine if you want
Is it normal that the dump path (for me) is /root/HW_PROBE instead of /root/HW_DUMP?
I also dont have a acpitable file, only acpidump ?
I have Xiaomi Redmi Book 16. I didn't find it in the list. Might upload its dump (when I reach to it) if there is interest.
This neat otherwise laptop has one irritating "modern feature" I would be glad to fix some day and it's in the ACPI realm. Namely, instead of providing a normal, the best for laptop STR (S3) sleep, these apple mimickers stuffed into it this "modern" bubble gum "feature", noone asked nor needed and blatantly called it "modern standby" or, iirc S0 low power idle. Like they couldn't coexist. So STR, that I like and use so much is not available! And this "modern stanby" drains the battery. Because it's some abomination, that is more suitable to tablets and phones, where it turns of display and something else, but not CPU. The thing is, there are reports that STR could be allowed. But by some guessing hackery around ACPI. of course, linux fans figured this, by torturizing the laptop in their attempts to make their uber marvel run on this hardware. Would be cool to dive deep and look what its aml can say about the matter. Dangerous but intriguing.
My laptop has it as well
In theory it shouldn't drain the battery
There is a spec for it
Modern standby isnât the problem there itâs windows
It does. That linux user, that made S3 back, complained in his blog (I wish I could find it for more detail), how the battery got drained, so he went through the ACPI hacking journey. This S0 idle doesn't turn CPU off and apparently many other components. For quick getting back (like STR wasn't fast enough). On mobile platforms with aggressive power saving technics in hardware, it works fine (more or less depends on the battery capacity
) but on a x86 laptop with performant CPUs this modern thingy is not that great with power saving. Such things as this, removing support for S3 in favor of this inadequate mobile thing is an example of clueless monkeying for the sake of looking "modern". In short, it sucks with laptops. It's basically always on scenario with display off. It may easily get active, by some update crap and you can hear as the fan wakes up to chill the system. How is it "more cool", than S3? You carry your laptop in the bag and meanwhile it sucks the dust because it is not in a sleep state, because anything, any program could do some background activity. And this all just to make bring up to 0.9 sec from 1.6 sec.
practically itâs just implemented wrong by MS, itâs only goal is to have the ability to do some event if you want,
If you donât check for updates every 15 seconds it doesnât drain nearly as much as youâd think
How so? That user didn't even use Windows, it was about linux. And xiaomi making STR disabled in ACPI.
I.e within 2% margin of error
Linux doesnât work with ACPI good anyway
so this kinda sounds like Linux just struggling to catch up and people being quick to point like a monkey at the hardware
Firmware developers arenât very smart but modern standby is a very simple thing it doesnât actually prevent you from mimicking something very close to normal s3 anyway
Meanwhile Microsoft is malicious, an intentional choice
The entire purpose of modern standby was to provide the utility to do some work while itâs asleep, the CPU has never actually turned off during sleep, not since core 2 days
The whole issue is in Xiaomi disabling STR. Should they leave it, there wouldn't be the issue. Those who wanted modern standby would use it, while those who wanted str, would switch to it. But xiaomi's crappy acpi reports no str. The guy needed to decompile aml, change it, compile again and flash it back. Guessing if it is going to make str back or brick the device.
I donât really disagree but the foundation of modern standby has replaced s3 for years now
Conventional S3 is a backwards compatibility feature that just makes modern standby look like s3
Weâre talking about 15 years not 5
You can still blame MS Though, as they required this to be considered a PC

This is in a total contrast to the ACPI spec that says that in sleep states there must not be CPU running.


