#Taratos (type 1 hypervisor OS)
1 messages · Page 2 of 1
jesus
i should write tests more often tbf
i caught so many stupid bugs by just bothering to write some test code
now i get it why 60% of infy's code is just tests
Literally this
Untested code is broken code goes a long way
Especially when it comes to regressions after refactoring
For kernel I just compile parts of it in userspace
Yes
all my err branches are untested 
I will have mature integration tests when the kernel itself is more mature
I'd rather have integration tests like Linux that run on the system idk
How lol
I just feel like unit tests often make you write tests just for the sake of writing tests
And u end up testing useless things that you know will work anyway
Hmm ill have to disagree
My way of testing is just torturing all the subsystems at once and see if something breaks
Like fireworks
Unit tests can cover every edge case in a simple easy to reproduce and quick to run manner
Can you give me an example
E.g. checking a virtual allocator rbteee range collapsing logic
Yeah but like
If you check that once
When you write it
No point in keeping the tests
idk
Thats actually very wrong
If you never touch any code again then sure, but this sort of thing gives you a piece of mind when doing big refactos or optimizations or rewrites later down the line
Id say regressions are even more important to test for
But then that'll show up in integration tests
Not unit tests
I agree that tests are useful, I just believe that it is not really useful to unit test something like a kernel where everything is intertwined, I do have unit tests for my library (rtl) though, but the rest will be tested through integration stress tests like most kernels
Integration tests are for testing integrations between components, they show you whether all APIs talk to each other correctly etc etc. But unit tests allow you to test components in isolation, and deterministically construct artificial edge cases or internal states are very hard to reach under normal circumstances
Imo both types are very important , you cant say one is useless and one isn't etc
first time in my life i use the into and bound instructions
honestly bound seems actually useful for certain loop shit if it set a CPU flag instead of an exception 
i think it does
Protected Mode Exceptions ¶
#BR If the bounds test fails.
compilers could optmise loops with bounds checks so easily
What did you use them for
im writing a test case for every exception
Ah
along with some edge cases (double faults, triple faults, not intercepting a contibutory exception but intercepting the second one, etc)
the api they have for kvm selftests is so nice 
it's the sloppiest code you will find in the entire kernel
slop as in sloppy or ai slop
slop as in slop
i had to patch a few things for my tests to be possible
because they don't test compatibility mode at all
so i introduced a new helper and unstaticated the ones that already existed
the patch is around ~500 loc of added code rn
Can you port kvm tests to your kernel?
if you implement the api, sure
they run in userspace
i don't know if anything internal is tested
Are you going to support kvm api?
maybe in 30 years 
idk, having the api sounds useful to me only if you want to port qemu
i see
@upper trout 
This person has commits to Linux on GitHub aswell
This could be good
I just realized that the broken bit that causes the GenuineIotel string is the LSB in ECX when returned by cpuid
I might be confusing the byte order but this is an interesting coincidence
@brisk saddle
This might be an issue in CPU-Z or something? Could also be an intermittent fault because we don't have any documentation about it persisting
There are tools other than CPU-z that report this no?
Eg steam and the intlastx report
True, forgot about those
I wonder if this is some cpu bug that can only be triggered under very specific conditions and that's why we haven't seen any complaints about it anywhere.
Or that atleast on windows it just dosnt cause any issues
And it's just there silently
I have two people who said they could have sworn they have seen it before aswell
And on Linux it would probably only disable a few things
And not break things wholesale
Depending on the severity
Poggers
ugh
int3, into, cause traps
but for these 2 instructions specifically, svm saves the rip pointing to the instructions

not a big problem, will save the pc of these instructions in the kvm run area
i already made a new field after the error code for a payload (for these instructions,the payload is the pc, for #pf, the cr2, for #db, the dr6, etc)
ngl if this patch doesnt get in i will be fuming
remember the kvm prefix for forcing emulation
it's complete garbage like the comment says
the cpu gets very confused and puts the rip much after the ud2 (so, the kvm instruction emulator cannot gather correctly the instruction to emulate)
at least the xen prefix gets assembled to something the cpu can execute even if it doesnt make sense to humans
sucks tbh, i dont know how to test whether the #ud filter doesn't clash with a #ud of an instruction that kvm can emulate
why do u need that?
several handlers (#db, #bp, #ud, #gp, #pf) are hooked by default
well, pf not exactly, only if youre not using nested paging
and i want to make sure that the exception filters dont break the default logic
Are you going to support nested btw
exceptions from nested guests?
Just nested guests in general
Yes
hmm
This
in the very far future ig
the biggest trouble is paging
you have to emulate it
well, not exactly paging, but nested paging
Cant nested guests use nested paging also?
yes, but the nested page tables are only 1
the nested guest can use paging with no problem
but, if the nested hypervisor sets up its own nested page tables for its guest, you have to emulate them
make the nested hypervisor think it has its own nested page tables, but in reality the topmost hypervisor manages them, and you fault on demand to fill them
Ah
kvm neatly handles this problem tbh
its mm subsystem (which is arch dependent) is generic enough to be able to handle ept/npt, and even when those are not available
Yeah its pretty well organized
btw some korean dude a month ago discovered a 0 day in that code
which allows guests to escape the vm
Yeah I saw that
i am going to cry
:(
if you intercept a #pf, the cr2 is not written in the guest cr2, but in the exit information
and when you queue an exception in kvm, you have to indicate the vector, error code, and payload
in the case of #pf, the payload is the cr2 value that will be written
the problem is that kvm calls the function for processing the payloads in the ioctls for getting the special registers (crX included)
so the state you read for the #pf fault is not exactly correct
i think i am going to ignore this problem
the problem i am having right now is that consecutive intercepted #pf do not contribute to a #df
which is done by kvm but for some reason it's not happening
when you intercept an exception, you get information as well on whether the exception has occurred during delivery of another exception
however, this is not happening consistently
my setup is the following:
- zero out offset to #pf handler in the idt
- cause a #pf
first you get a #pf, then you get another #pf because the handler is not mapped, so it gets transformed to a #df
between the time i inject the first intercepted #pf and the time the second #pf occurs, the "hey mr kvm, this #pf happened during delivery of #pf" is gone because of a bunch of vmexits
What are you doing exactly rn
working on the patch
trying to get double faults working, when the exceptions that cause them are intercepted too
Ah
fucking nested page faults 
theyre the ones that are making kvm forget theres an exception happening during delivery of an exception
well, the vmexit reason can also be anything other than that
now i have to think how to make this work
hmm, actually not, the nested page faults still have that information
the moment i get the second #pf that info is gone
in short, when i get the second #pf the cpu and therefore kvm forgets that it has happened because of another #pf, and kvm can't inject a #df to the guest
i'm not sure there is a way to fix this problem
the essence of the problem is that i have to know whether the cpu has started executing from the exception handler, or whether to morph it to a #df
and that sounds complicated to figure out
moreover, this only applies to #pf, because the handler is unmapped, what is the code segment is not present? or the idt entry is invalid? or whatever else
i have the same problem but with the #np/#gp/#whatever exceptions
i think i have probably corrupted the kernel (a lil bit only)
the cpu correctly includes the previous exception information on the 428th page fault
time to activate all nuclear kconfig options
oh god... why was WARN_ON_ONCE not enabled
yeah, according to claude and gemini, if you inject an exception and there is an exception while trying to deliver it, the information is recorded
so no idea why tf it is zeroed and only made available after this comical amount of page faults
im probably missing something in the overcomplicated way interrupts are delivered
i will look into it tomorrow, atp ive been struggling for 5 hours
You could also leave double fault stuff as a TODO?
This is still valuable to properly have anyways for other faults
how do you see this info
It was last year's discord checkpoint thing
im trying to get a bit higher of a ranking this year

you don't get it if you have data collection stuff disabled
How do you know
you can just enable it when it happens and then it pops up
search by:evalyn
Why did you even search that lol
idk
damn ev you have over 2x as many messages as me and I've been here for way longer
i have 55k
so they still collect data :^)
who would've thunk
It's called having nothing to do all day
The og gdt days
Pretty sure atie taught me how to do gdt lol
it's highkey insane to see how much the hobby osdev space has improved
Back in 2020 when I didn't know anything
I don't want to go back and look at those messages tho
lowk
my most legendary message is this
when i first joined
too embarrassing
#osdev-beginner-0 message
maybe i wasnt that bad 
I can't see that message
tbh i spent 9 months to that point only writing real mode brainrot
Where is it
archive access
and not very advanced really
the most i have done is int 0x10 hello world
Ah lol I remember I stole your naming convention
I got the real mode brainrot out of the way by making bootsector snake and then just using a sane bootloader. Long live the days of Limine version it would've been like 2 or something, and Stivale2
real ogs remember qloader
qloader2
honestly somtimes i feel a little out of place considering i got here so late
But I'm glad you are all my friends
I think you learned pretty fast tho
Yeah
Though I still have some moments where my brain likes to be slow 😭
But once I understand something I can get going fast
eh
in a few months you got your os in multiple arches, in that same time i was struggling to understand why my crap real mode os worked on windows qemu and my usb and not in linux qemu 
tbf the resources have improved so much
A big thing I learnt from my first one was to not rush myself and to take breaks
like back then we were all mediocre helping others to be medicore
My os has been coming up more slower but it's gonna be nice
What was the issue
Especially once I finish all of the refactors I want to and get it to a place in really happy to
me using hardcoded values for ah=0x02 int 0x13 which i had copied from tutorial oses
Lol
well, apart from limine and mlibc existing, and this community providing proper guidance i don't think the resources are better
i think we just got more used to read books and real oses
Limine is also something somebody else would have made
Even if it took longer
Like Multiboot3 or some crap
most ppl were using multi boot with a long mode trampoline
In the year 3694 but still
We are less idiots is what I meant
no one had thought of making a bootloader with a custom protocol
i think the main reason mint started qloader is because grub didn't work with freebsd
So it's easier to guide beginners
Also beginner osses are now full vibecoded gui and doom ports instead of gdt init
I do wonder if there are other osdev communities outside of this circle / the forums / the other discords we don't talk about
Irc but thats mostly dead
the biggest one is probably the french osdev
I mean we still get GDT init okays
idk if it exists still
Actually slightly wild story
A person on reddit with a vibe coded GDT init okay thing
They leaked their API keys in the repo
So I joined their discord to tell them
I met two other friends
It's pretty much dead sadly
And by that chain of reactions I ended up coming here
Only a few messages per week
I think the only other big community is irc
We are the open osdev since we force source for every project
I mean
There are splinter groups from here
That are private
yeah ik
there's also unmapped stack's community I think
That and nanobyte and racistosdev
Those servers are funny
there also used to be low level development for teenagers
Is that still a thing
its just a place for people i .!naenae to mald
it seems it still exists
They all died after covid I feel
i should leave that server since im not a teenager anymore 
french osdev and lldt
i dont like the idea of a server for teens
seems like a quick way to get pedos infesting it
why is reading from the trace pipe make linux panic on null deref 😭😭😭
it dosent?
i tried reading from it
nothing happened
they are modifying it lol for kvm
i mean im on kernel 7.0.13 or sum, is it happening on a newer kernel?
They are modifying the Linux kernel
To get better information out of KVM for interrupts
cool
For QEMU logs
this is so fucking odd
always after the 426th injection, the cpu realizes the #pf is because of a #pf, and then kvm is able to inject a #df instead
what is the chance this is a nested bug
Its a decent chance because nested has been very buggy since its inception
do u know a way to test this shit in real hw easily
something like virtme-ng but makes something bootable and runnable
Well installing a custom kernel and rebooting into it is not very hard
But debugging it if it dies is harder
well, yes
but if i want to install that custom kernel, id also have to build like 600 unrelated modules
That takes maybe like 10 minutes on a decent PC
Just copy your distro config
And you need to do it once
Then later rebuilds can keep the same stuff
Lol
time to go nuclear and dump all register state on enter and exit
this was a linux bug btw
wrote a quick patch, got a reply and it's getting in soon 
What's the issue atm
so the way this works is like this
i set intercepts for all exceptions
most exceptions are not intercepted by default by kvm, only a few are (#db for guest debugging, nmi unmasking, #bp for guest debugging, #ud for some meme, #gp for some nested virt memes and vmware ioport, #pf if not using nested paging)
^ actual list depends on whether you're using svm/vmx, from now on, assume svm
for those exceptions that are not used by kvm for some internal reason, the action is to enqueue the same exception (this means that, before the next entry, inject the exception [write a field in the vmcb so that the cpu automatically starts servicing an exception])
for the other exceptions, i take care to distinguish whether the reason the exception is intercepted for an internal reason or because the user wishes so
when you vmexit because of an exception intercept, there is a possibility you have intercepted an exception during the delivery of another exception
example: say you intercept page fault exceptions, and the handler for some exception is unmapped
let's suppose you trigger a #gp and the handler is unmapped
so, you'd vmexit because you intercept #pf
and the cpu will also tell you that you have intercepted #pf during the delivery of a #gp
kvm handles this correctly, it will enqueue the #gp, and then when my exit handler for #pf enqueues a #pf, it will see that the last exception is a #gp and will change the #pf -> #df
what happens now if i intercept #pf, i have the handler for #pf unmapped, and cause a #pf
the logical and correct course of action is the following:
----- vmenter -----
mov rax, [unmapped1]
----- vmexit: #pf -----
- enqueue #pf back into guest
----- vmenter -----
service #pf, get a #pf while doing so
----- vmexit: #pf during delivery of #pf ----- - enqueue #pf
- enqueue #pf -> last exception is #pf -> actually enqueue #df
----- vmenter -----
service #df
what actually happens:
----- vmenter -----
mov rax, [unmapped]
----- vmexit: #pf ------
[repeat 4 times:
----- vmenter -----
- service #pf
----- vmexit #npf while delivery of #pf -----
^ the nested page fault happens because it's trying to read the idt, trying to read where the handler is....
]
----- vmenter ----- - service #pf: handler is unmapped
----- vmexit: #pf -----
see where the problem is?
there is NO "while delivering #pf" in the second #pf
so the cpu starts looping and vmentering/vmexiting from page faults
because if the cpu doesn't say so, kvm doesn't know "while delivering a #pf", so it can't inject a #df
and the odd thing is that ALWAYS in the 426th intercept, the cpu finally decides to put that information
and then it correctly injects a #df and etc
so yeah , i think i am going to better spend my time if i start working again in my os
i have a dream (running linux with passed through devices)
so, if the user had no knowledge of the intercepts, this wouldn't be a problem
maybe you would see some extreme latency when getting double page faults
but it's specially annoying if you set -d int in qemu and get hit with 52937484930228 page faults with the same register state
I mean, qemu could technically de duplicate these from the log right?
i feel that's an ad hoc solution
And if it's always you can always just do a // HACK 
Fair but are there other ways arround it?
i haven't tested other combinations of exceptions for double faults
but #pf -> #pf is very problematic, as you see
If you get page faults constantly in a row buffer them until it could be a df or something else 
Does it really have to be perfect for the initial series?
i feel i will be clowned if it's not good enough and there's problems like these
I mean the iotel issue wasn't clowned on
You just have to justify it
And then they will either say it's fine or it needs more work
I do but im a bit far away from my PC atm
Im afraid im away for a bit longer lol, out of town with the gf
respectable and based tbh
I do, I could test in a little bit if you give an ISO
iso not really
install virtme-ng
i will send you patches and what to clone, tomorrow though
@clear agate do you happen to know if there is something odd in svm when injecting an exception, and the delivery of that exception causes another exception?
read this
nothing comes to mind, the triggering of another exception should be forward progress, there's nothing particularly wrong with triggering an exception when trying to process one (thats going to double or triple fault fault though), though I'd have to check the manual to see if the exit gets triggered as the new exception (if you have the exit control set) or doublefault...I suspect the new exception would exit first before it becomes a doublefault and now you need to deal with that. But based on what you wrote I dont know what the situation you're asking about specifically is
okay
let me be more clear because i think i vomited yesterday a word salad
it's a bit hard to explain
----- gap -----
suppose i have the following setup:
- #pf intercepted
- in the guest, an instruction which causes a #pf, and a valid idt entry for #pf, but the handler is unmapped
the only reason i intercept #pf is for tracing purposes, i am not doing anything special with it because npt is setup, so the only thing that is done in the intercept handler is to inject back the #pf
ok, so this presumably will lead to another pf
yes
when the instruction is executed, it causes a #pf
it is injected back, and the guest should exit again, with reason #pf and informing that it has been caused during delivery of #pf
but you cant respond to that with a pf legititmetly
and then i should inject a #df instead
maybe?
sorry 😭
the issue is that, when you vmexit, the cpu tells you the reason (#pf intercept), and if the intercept has happened during delivery of an exception
ok
so i should get basically
- exit reason: #pf interception
- exit_int_info: during delivery of #pf
the problem is
exit_int_info is 0?
and the cpu proceeds to loop 426 times exactly, it exiting only saying that a #pf has been intercepted and me injecting it back, until it finally fills the exit_int_info and then i am able to inject a #df and continue as normal
i am just asking you whether you have heard anything weird going on with exception injections in svm
if not then dw, i will try to debug even harder and you can keep playing factorio 
the reason i am messing with shit like this is because i am trying to implement -d int for kvm (only the exceptions part)
exactly 426 times sounds more like some state somewhere is changing
yeah, it's very weird
the only exits that happen are for the #pf intercept and some #npfs, which i presume are for trying to resolve the physical address for the idt and the page tables possibly mapping the handler at address 0
i confirmed that this is not a kvm nested bug
JW plays factorio?
try it on vmware maybe, but it makes me suspicious if youre not injecting the right shit back in, the notes in the apm around this arent entirely clear (or simple)
but no, I wouldnt be surprised to find out you never get the signal that it was during an idt processing, but getting the signal eventually...doesnt sound very amd
(it does sound very intel)
doesn't sound very AMD?
ah okay lol
hmmm, I am sure i am injecting it correctly, there's a tracepoint for it in kvm
the #pf when i intercept the #pf
yeah, but I can't
because svm is not telling me that i got a #pf during the delivery of a #pf
it's missing the last part 426 times
so i am constantly looping and reinjecting the #pf until i finally get the info
that still makes me wonder if you injected somethign wrong then, cause it doesntmake sense, what are the other fields showing, i.e. did the faulting address change or not
yeah, could be getting fucked by weird kvm shit, try a differnt hypervisor too
when you queue an exception for injection, you can associate with it a payload
for the case of #pf, it's a cr2
so basically, when you queue the exception (which i do after work exiting), the next time kvm is about to enter, it will inject the #pf and write the value to cr2
yeah, I"m more focused on the exit info atm, that would tell us if you properly are making forward progress. Alternatively maybe dig deeper into kvm to find exactly what you are writing into the hardware
the weird thing is that this action (which kvm calls payload processing) is also done when you use the ioctl for getting the crX registers
dont care what kvm is doing, you asked a svm question
i have also tried to not get the state of the register, but the same shit happens
up to you to isolate if kvm could be getting in the way here
the thing is, im patching kvm
so idk how that will help
i am going to try doing the same thing in my os, now that i have svm running in it
well good luck, make sure kvm isnt trying to run its instruction emulator
and see if the same 426 times looping shit happens
that might be how it's escaping its loop btw
also if youre attached to qemu make sure it didnt get kicked into user to resolve
well, the ultimate purpose is to support -d int with kvm, but i am not using qemu to test the changes
the modified kernel and kvm runs in qemu but i am testing my changes with the kvm selftests api
so you have your own thing running kvm ioctls then, ok, still make sure it didnt run the kvm emulator, it probably isnt but kvm is weird
👍
does vmware have something similar?
to -d int
if it does, then it's 100% a skill issue of mine/kvm issue
or vmware is using some
tricks
it does but I dont remember the config options, https://williamlam.com/2010/10/1200-undocumented-vmx-parameters.html has a bunch listed, there's something like an exception bitmap somewhere
log.somethingsomethingsomething
I just took out a big demolisher worm with nothing but gun turrets, and crapped on this channel with off topic nonsense. Now if there's someone to ban this day will be perfect
Fuck yeah
That reminds me I should play Factorio again 😭
hmm, gonna try diffing the vmcbs
before enter and after exit
btw, have i mentioned that i love linux tracing
fuck me, theres like 30 fields that change every time
lets see if there is anything special in the 426th™ enter
omg i love claude
let's see if it has extracted anything meaningful from the dump i have provided to it
LMAO
LMAO
LMAO
jesus CHRIST
WHY THE FUCK IS THE STACK POINTER BEING DECREMENTED
how is this even supposed to work
let me write a quick poc
apparently, i
- inject the #PF
- the CPU fabricates the exception frame (decrements RSP)
- tries to jump to the handler (which is null)
- CPU gets a #PF -> i intercept it
- repeat
so the RSP gets decremented infitely until writing the frame faults, and this is when finally i get the info that i have a #pf cuz of a #pf, and i can inject a #df instead
hmm, might i be actually retarded and interrupt delivery is not supposed to work like i think
like, if the cpu jumps to an unmapped handler, the #PF doesnt contribute at all to a #DF and this all has been correct behavior
the manual does not say anything about this
yep
fuck me
unmapped handlers do not contribute to #DF
the CPU simply sets the RIP to the handler, and if any exception happens from so on, it is independent
so you will fault when your stack underflows
rsp is ffff800007f4ff98
causing a #PF, handler is unmapped
panic: double fault at 0000000000000000, stack FFFF8000079EA010```
@clear agate ^
well, at least we are balling now, this could now be a patch
although i have to rebase it now, because the x86 kvm tree has new additions 
aha, so there was state changing, told you so
yes
cool
i have to write a cmpxchg128 if i dont want to suffer updating amd iommu device table entries 
atlest CMPXCHG16B should exist on any device with am amd iommy right

sphinx + doxygen
realized that down the line i am going to forget almost everything i have written, so why not start documenting
May I recommend my documentation generator
it's used by uACPI
I built it because sphinx and doxygen are annoying together and I just wanted something that worked
eh
I also had managarm docs generated but I forgot to ever PR that
it has been only 2 commands (for the moment)
Especially when you also want extra pages
Then you use sphinx and breathe and exhale and whatever
after working for 2 weeks straight only with linux code i realize my kernel code quality is garbage 
dddtppds

just put each letter of the alphabet for function and when u run out make if 2 then 3...etc

a9
lol
also chess move ahh name
what kind of chess board are you playing on 🥀
a secret turkish one
no
jesus
the qemu implementation of the amd iommu is BALLS
gg
the passthrough mode is broken
it doesn't take into account the read/write allowed setting by the os
it only takes that into accout when its necessary to walk page tables
yep
this is hilarious
if i set up a page directory with all 0ed, works as expected
why am i so disgraced
every time i try to make something non trivial it always breaks because of someone else
youre given opportunity to contribute to stuff
tbh every time u dig deep this happens
happened to me with acpica, linux log ring etc
i ended up fixing their stuff
fair
well, it's time to go on a tangent now and see how i can fix this
working with the qemu memory api sounds like 
(this is working with any qemu api tbh)
tru
hmm, this is going to be tricky
i am not sure if qemu has the concept of write only memory regions
nope, it doesnt
there's only read only, obviously
"what if you came over and we sensually read eachother the kvm nested virt source code" - me courting my wife in 2014, probably
I think this is literally you
lmao
the qemu testing api is so bad it's incredible
the interfaces are abhorrent, and i realize almost nothing is even covered by tests
the amd iommu tests is literally
AMD IOMMU enable... ok
otoh the other iommus (intel, virtio, riscv) seem to be thoroughly tested
I guess this means if I ever did try and cleanup QEMU TCG Fred I wouldn't need to make tests
😭
eh, i guess that tcg is properly tested
but i just found it very funny that for most devices, almost nothing is tested
at much if it initializes correctly, or some very specific niche thing
the api for testing is super terrible too
I mean stuff like interrupt delivery sounds annoying as fuck to test
Example?
for example, you want to create a machine
qtest_init("qemu arguments")
which is ok ig...
but then, say you want to get access to devices
you have to call qpci_pc_init or something like that
which is like a weird name
and then idk, the api for accessing memory and io ports seems fine (it is hard to fuck up that)
but the thing is that there's like 3000 ways to do the same
"initializing" a handle to a PC instance and then getting devices etc is one way of interacting with devices
there's also some QOS iirc brainrot which works with nodes and edges and blablabla
overcomplicated
and qemu uses glib 
But I know I definitely wont do it however the fuck qemu does it
ask infy or someone else, they def have more experience than me with testing
tbf the only time ive written tests in my life was for the kvm selftests/qtest which aren't very pretty interfaces lol
- Integration: make a python script with pytest (or any other language with any other test framework), in the test run qemu with some kernel command line that makes the kernel do something. Make the kernel output some magic bytes at the end for pass or fail, consume them and fail or pass the test
- Unit: I personally just build parts of kernel code in userspace, with arch specific parts stubbed if required (e.g. irq disabling), then its just normal unit tests from there
I think rdmsr has a userspace build variant right?
Maybe I could hack something like that together for some things
He dropped it because a full userspace arch is a lot of work
For unit testing you need much less
something like uml?
Oh yeah fair
Yep
oh yeah that sounds painful
oh yeah
i think that you have to provide the qom path for the irq pin
ok no, of the device, but i haven't figured out how to attach a handler/work with msis
im just polling the iommu and the edu device (which i am using for testing dma)
When I asked clanker about qemu APIs it was generally fine
If you give it the src locally especially
Maybe try that
ngl i used claude for telling me which functions i have to use
as an agent or the webui?
the web ui
if you want cheap af agents opencode go is cheap af
plus its only OSS models
and aparently grok??????
lol
starts inserting racist remarks in my code
It's like 5 bucks a month for the first month
And 10 bucks after that
And it's pretty generous with usage
Except for grok
Which is super fucking expensive 😭
But it's a flat fee instead of it charging you how much you use so 
It's nice for more basic tasks since the LLMs aren't thatttt smart but good enough
for writing tests i get their appeal
yayayay
iommu code works in real hw
most importantly, target aborting the nvme controller does not break it
my objective for today and tomorrow is to implement mapping arbitrary gpas -> spas, and to also support pasids for gvas -> gpas -> spas
Fun fact I once broke @royal frost IPMI thing on their server by poking random physical memory to try and get machine checks with bad ECC ram 😭
hai again
can confirm, had to reflash
Wait do you have devices with IOMMUs
Could be useful to test this
Esp on fancy servers
IOMMU is on the CPU
the latter case is quite interesting not because i have pasid aware drivers (although the amdgpu has pasid support, which ig is used for kfd), but because you plug a cpu page table directory directly
like any semi modern laptop has iommu tbh
Yeah but if they wana test the RMRR things sever boards may be needed?
and the AMD iommu has a special mode where you can configure it to treat no pasid tag for a device as if it has pasid=0
oh not sure
so you can do a spa=gpa setup, and then use a cpu page directory for a device directly
and the best part is that amd nested page tables are exactly the same format as the cpu ones
so i don't have to duplicate page tables
i can plug the nested page tables for the device and for the virtual machine
amd is based tbh
How close is stuff to getting into booting something like SEABIOS btw? (I also wonder how insane it would be to run the systems firmware on the hypervisor instead)
seabios is easy
well
i have some haswell-ep xeons (that collection you saw + e5-2673 v3)
and then xeon scalable 2nd gen (gold 6138)
Honestly why would the pte format need to differ 😭
you have to emulate a very specific subset of q35 to get it working
and that's it really
Huh neat
Il have to uhhh get inspired by that if I ever make an x86 emulator (and re using an existing decoder because fuck that)
so that seabios can get the acpi tables and the e820 map
this means that i have to be writing my own aml

Make the worst AML you can to make infy cry
yes

but before i get to the point where i get seabios working
i really want to have rcu
and have something like the memory regions in qemu
because in x86 the memory map is quite volatile
you have smm, bars, etc etc
and ion feel like using a lock when doing mmio
and i want to have a system where i can easily specify memory regions, aliases, overlap them, etc
do freebsd GUS instead
btw qemu uses rcu
memory regions are converted to what's called a flatview
which is well, as the name suggests, a flattened view of memory
and accesses to this flatview are under a rcu lock
nah
im too uncreative, i think im doing hierarchical rcu
ill just copy linux
RCU is useful because you dont really need to adapt data structures for it
yeah, this is not happening
i got rightfully distracted by the world cup and today i spent my day goofying around
i will try to get at least gpa -> spa mappings
which is going to be super ez because i only plan to map 4kb and 1gb pages
now i have to do unmapping and freeing (
), after doing so flushing local and remote iotlbs, write the code for double transations, and make a device io memory allocator
which will have to take into account p2p zones, exclusion ranges, and the hypertransport range bs
invalidation is so fckn weird
you can specify custom page sizes
but if you use high enough addresses, the iommu thinks you want to invalidate all the cache
because of the way size is encoded
i am reading about virtio iommu
why is it so based

no page tables to manage
actually this is so cool
i could support only virtio iommu for the guests
virtio is pretty cool
and then if i have passed through devices
the guests can have another layer of translation
i can set up for the device the GPA -> SPA translation tables (which will have the same mappings as the nested page tables)
and then the GVA -> GPA translation tables, which will be modified accordingly with what the guests want
indeed
good shit
during negotation, you can specify the valid virtual address range
honestly this is not a bad idea for general usage
so i can exclude the non canonical address range
.
hyper-v does similar and like only uses its virtio clone for a ton of shit
here i used 6 level paging
look at the addresses
i think i will be supporting only virtio devices at the beginning
speaking of funky addresses, are these valid or invalid, and why
yes
im guessing la64
a loong one
yes
what did i delete?
well, it's time for the last thing
i have invalidations done
time to support double translations and then move on to rcu
I do wonder if you can guess what makes thoes address like that
Ah lmao

DMWs are cool though
yeah
It has exceptions for hypervisor shit
I presume it should be possible
Though it's uhhhhhh
Fully undocumented
lol
i mean, if your arch is well designed you don't need extensive hypervisor specific support
x86 was just bad from the beginning
😭
Trueeee
Riscv may actually be worth it later though
Since rva23 mandates the H extention
And more and more hardware is coming with that
i have heard that the god of qemu/kvm had a hand in the design of rv hypervision
so it's a good design
not really 
qwinci has done riscv hv for managarm
and fadanoid for keyronex
they say it has been very simple
SBI is actually also really well designed
It's basically intended to be paravirtualized and shit
Since it's basically like a syscall but from the kernel into firmware
Well it's exactly that to be specific
i see
Same instruction and eveything
til
my non-x86 knowledge is very very lacking
the only non-x86 arch i have worked with is mips because they teach us that in uni
Honestly my favorite part of it is that it gives you a print function
So you get port E9 even on real hardware
cool

But yeah
Consider a riscv port
It's koolio
maybe for another project
something good about nvmes
they don't seem to shit themselves after getting target aborted
they keep going, and ig the abort is logged somewhere
(apart from the iommu telling you)
rn i am trying to debug double translations
it is page faulting, with the reason that there is some reserved bit set to non-zero
surprisingly, it encounters that bit during gva->gpa translation
i like it
My lawyers will be contacting you soon
_ _
🦀 🦀 🦀
gva -> gpa mappings work
basically, i fucked up a shift
the pointer to the pasid table is split in 3 pieces in the device table entry, and one shift was off
time to push
so, i am done with amd iommu dma remapping
there's not much more what to implement for it
i don't think interrupt remapping will be too useful for me
but one thing i 100% want to support is interrupt posting
if your hardware supports the avic (advanced virtual interrupt controller), which means that you can set a pointer to a page in the guest state which will act as the apic page, and the hardware will treat io and msr io to that region as if it were a real apic
Did you like the linux amd iommu state machine
Damn
Did you do it from spec entirely?
yes
Cool
so like
you discover the iommu from the apic table
but then to control msis, you need its pci_dev struct
but if you initialize the iommu before pci, then you naturally dont have it
and at the same time you want to bind pci devices to the iommu during the first pci discovery
so you have many steps of initialization
Did you do Intel yet?
at least thats what i do but i suppose in linux its the same story
nope
i do whatever my laptop supports 
Imagine only having one laptop
But u can pick up a used relatively modern one for very cheap
yeah
Anything post 2012 will probably have an iommu
Is that like a netbook
writing a driver for it will be interesting
Yeah i2c stuff on x86 is kinda annoying, iirc the controllers aren't documented at all
yeah, something like that
Oh ok
its discoverable with acpi
Yeah but the smbus device at 1F.X is not documented
The devices behind i2c are discoverable ofc
Cool yeah it tells you which i2c controllers its on and how to talk to it
is the interface standardized?
no i mean
It also usually starts in D3 cold
the commands you have to send to basically work with the touchscreen
So you have to wake the PCI device itself
Yeah thats standard hid over i2c
Most likely
ah okay cool
oh okay i think i get it
the aml tells you the offsets, but you have to talk with smbus/i2c yourself
and that depends on whatever chipset you have
You have the standard i2c protocol, which is relayed over SMBUS on x86, but then you have the hid protocol on top of the i2c wire
Yeah
Smbus even exists on QEMU
when you run lspci on this laptop, theres a lot of signal processing controllers
yeah ik
but it doesnt do much
it doesnt even fill the correct spd info i think
Im not even sure what it does
Yeah
see the Link
Its probably also just there to mimic the full q35
so its not even at smbus using the south bridge interface
yeah but link is not some standard aml name, that's a private thing inside that device
Isn't this whole thing under PCI0 anyway
yes
Wdym by that?
let me get that laptop and run lspci
there's a lot (around 10) signal processing devices
i think the i2c for the touchscreen is basically under one of these
what is the south bridge interface?
i wonder what controller these i2c signal processing things use
like is it different from an smbus controller
why the hell do they have incrementing device id numbers 
drivers/mfd/intel-lpss-pci.c: { PCI_VDEVICE(INTEL, 0x5aac), (kernel_ulong_t)&apl_i2c_info },
Device (I2C3)
{
Name (_ADR, 0x00160003) // _ADR: Address
}```
so basically the touchscreen is in the 4th signal processing contrller
the driver is tiny
but thats probably because the bulk of it is handled via some parent driver
theres the acpi part also https://elixir.bootlin.com/linux/v7.1.4/source/drivers/mfd/intel-lpss-acpi.c
it doesnt apply here tho
yeah, probably because its discoverable via pci anyway
anyway even the core driver is tiny
but idk if thats the entire thing
drivers/platform/x86/x86-android-tablets/other.c: .dev_name = "FTSC1000",
drivers/platform/x86/x86-android-tablets/other.c: .dev_id = "i2c-FTSC1000",
drivers/platform/x86/x86-android-tablets/other.c: .dev_name = "FTSC1000",
drivers/platform/x86/x86-android-tablets/other.c: .dev_id = "i2c-FTSC1000",
huh lol
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci
unless theyre being stacked
idk if my laptop qualifies as an x86 android tablet tbh
nah, if i had to guess, they put the ftsc1000 i2c device inside they soc
but its not discovered via this code path
DMI: MEDION E3213 MD60774/NT13A, BIOS V2.0.4_P2S0T1P1F3G2C2 07/06/2017
static const struct x86_i2c_client_info vexia_edu_atla10_5v_i2c_clients[] __initconst = {
{
/* kxcjk1013 accelerometer */
.board_info = {
.type = "kxcjk1013",
.addr = 0x0f,
.dev_name = "kxcjk1013",
},
.adapter_path = "\\_SB_.I2C3",
}, {
/* touchscreen controller */
.board_info = {
.type = "hid-over-i2c",
.addr = 0x38,
.dev_name = "FTSC1000",
.swnode = &vexia_edu_atla10_5v_touchscreen_node,
},
.adapter_path = "\\_SB_.I2C4",
.irq_data = {
.type = X86_ACPI_IRQ_TYPE_APIC,
.index = 0x44,
.trigger = ACPI_LEVEL_SENSITIVE,
.polarity = ACPI_ACTIVE_HIGH,
},
}
};
yeah this is hardcoded for some other thing
/* Vexia Edu Atla 10 tablet 5V version */
.matches = {
/* Having all 3 of these not set is somewhat unique */
DMI_MATCH(DMI_SYS_VENDOR, "To be filled by O.E.M."),
DMI_MATCH(DMI_PRODUCT_NAME, "To be filled by O.E.M."),
DMI_MATCH(DMI_BOARD_NAME, "To be filled by O.E.M."),
/* Above strings are too generic, also match on BIOS date */
DMI_MATCH(DMI_BIOS_DATE, "05/14/2015"),
},
.driver_data = (void *)&vexia_edu_atla10_5v_info,
that seems like a reliable match 
yeah
* DMI based code to deal with broken DSDTs on X86 tablets which ship with
* Android as (part of) the factory image. The factory kernels shipped on these
* devices typically have a bunch of things hardcoded, rather than specified
* in their DSDT.
*
oh wait this is a spanish tablet
funny
/*
* Vexia EDU ATLA 10 tablet 5V, Android 4.4 + Guadalinex Ubuntu tablet
* distributed to schools in the Spanish Andalucía region.
*/```

Android people even manage to make x86 proprietary
documentation is now live at https://atiep.github.io/taratos/
here i will be documenting APIs and internal design
as well as stuff i find interesting
github actions is so great btw
the last time i had done anything ci/cd related in github was with travis back in 2020
it wasnt very good lol
now you get machines with 4 vcpus and 16gb of ram and whatnot for free
this is cool
I might or might not try to figure out how to do something like this with the zig docs thing
but anyway, it's nice that you care to document your stuff for others to use and for people to contribute
the main reason im starting to document is because i will end up forgetting how most of my os works 
but yeah
i also wanted to try out sphinx and doxygen and actions and blablabla
once my os is more usable and not just a black screen with white text and a halt at the end i will make an action for building it
I forgot a bunch of stuff from mine as well lol
sometimes I look at code and trying to figure it out
same
I'm not sure if I wanna commits to docs though because the API is likely to change and it's annoying to update

