yeah ig the NVMe driver should handle the case where only a single MSI vector is available
#Managarm and related projects
carmine current
the thing is, it doesn't die in nvme but in hw protocol
vestal sapphire
also error handling the the installMsi func should be improved 
carmine current
And I don't really see how the request can fail without logging an error in thor
Since the relevant error paths in thor do seem to log (?)
Oh yeah
upbeat smelt
if ((msiIndex < 0 && msixIndex < 0)
|| !parentBus->msiController
|| req->index() >= numMsis) {
managarm::hw::SvrResponse<KernelAlloc> resp{*kernelAlloc};
resp.set_error(managarm::hw::Errors::ILLEGAL_ARGUMENTS);
FRG_CO_TRY(co_await sendResponse(conversation, std::move(resp)));
co_return frg::success;
}
``` doesn't logActually what might be happening is that the first MSI succeeds and the second fails
You're right
upbeat smelt
i bet the nvme controller only has msi and not msi-x
and for msi we only support one since it has some special irq number constraints for multiple msis
carmine current
yeah
So i guess the easiest fix is to route both admin and io queue to the same vector
If there is only a single msi
upbeat smelt
coming back to this because now i'm curious firefox js console sez
and logs to somewhere (stdout/err?) ```
Mar 02 13:48:05 selenium firefox-bin[2937]: [Child 2937, MediaDecoderStateMachine #113] WARNING: Decoder=7fad48e77700 state=DECODING_METADATA Decode metadata failed, shutting down decoder: file /builds/worker/checkouts/gecko/dom/media/MediaDecoderStateMachine.cpp:372
Mar 02 13:48:05 selenium firefox-bin[2937]: [Child 2937, MediaDecoderStateMachine #113] WARNING: Decoder=7fad48e77700 Decode error: NS_ERROR_DOM_MEDIA_METADATA_ERR (0x806e0006): file /builds/worker/checkouts/gecko/dom/media/MediaDecoderStateMachineBase.cpp:168
fast silo
holy flicker
upbeat smelt
and logs to somewhere (stdout/err?) ```
Mar 02 13:48:05 selenium firefox-bin[293...
okay i think this is https://bugzilla.mozilla.org/show_bug.cgi?id=1945371
vestal sapphire
So i guess the easiest fix is to route both admin and io queue to the same vecto...
yeah that's the solution for when we have a single vector generally
we'd basically just need to keep a list of which queues are attached to which MSI vector
I'll be home later today, I'll take a look
this doesn't seem to be very hard
I'll tack it onto my random fixes PR
nocturne tide
isn't it enough to do something like
const queue = co_await initializeQueue(...);
const msiPin = co_await initializeMsiForQueue(queue);
runDetached([queue, pin = std::move(msiPin)](async::cancellation_token ct) {
while(!ct) {
co_await pin.waitForInterrupt();
// handle interrupt
}
});```
can't you just kick off an async routine that handles the interrupts and you capture the queue? that way you don't need to keep track of queues anymore, unless i am misunderstanding how async stuff works in managarm/c++idk if detached coroutines get a cancellation token or not, i am just coming up with random stuff lol
lament grove
I'm unable to download this
It fails right at the end
NVM I got it downloaded
NVM², I get this error: zstd: riscv-image.zstd: unexpected end of file
mild jetty
NVM², I get this error: `zstd: riscv-image.zstd: unexpected end of file`
downloads and decompresses fine for me
lament grove
I'll try again I guess?
mild jetty
for reference $ b2sum riscv-image.zstd c62cb35fb166f8ba18ea7e80208634506481614969643b69ad4850887395af407c213c06955e28289f9fa1ed82968476472e9ebb478a722c862b84a2b8b4b8fd riscv-image.zstd
lament grove
After a total of 10(!) tries, I have successfully downloaded and unzipped it
lament grove
I'm going to create a new image with the proper partitions now and see whether it boots
mild jetty
on qemu it seems to get stuck here (when attempting to boot into kmscon)
oh nevermind just took a while
lament grove
Just copied it out of the loop devices, now I will steal the U-boot partitions from BadgerOS.
lament grove
Turning it on now...
vestal sapphire
Give hwdb a good minute or three depending on hw
lament grove
GPT partition not found, I must have messed up making the ISO...
lament grove
I'm going to erase the entire SD-card and try again
lament grove
Well at least the error is different now
The error code indicates that a trap happened before U-boot could do anything
lament grove
Man, trying the SD-card many times at 30MB/s write speed sucks
upbeat smelt
Man, trying the SD-card many times at 30MB/s write speed sucks
all my usb sticks go at like 4MB/s write speed
that i use for testing
lament grove
holy shit
Got it loading Managarm. For some reason, trying to directly use sgdisk doesn't work but making an ISO and then flashing that does.
Managarm, however, is less happy:
Now I would send you the ISO with a drive link except I don't have enough remaining storage for that.
carmine current
Hmm alright ty
lament grove
What I can do is send the offending DTB:
carmine current
That's nice
I'll try to find out why it triggers and assertion there later today
lament grove
If you have a new kernel for me to try just send me the file, it'll be easier than remaking the entire image :P
carmine current
yea
Also it's nice that uefi + eir-limine works on that board
That code path was not tested on real hw so far
Because the uefi implementation is broken on the boards that i own
carmine current
Apparently it's good enough on this board though
lament grove
U-boot is the recommended first-stage bootloader and it has an official config for it.
carmine current
On the bpi-f3 uboot segfaults in ExitBootServices (uboot faults, not our code )
lament grove
If I do it right I should also be able to make something stored in the internal FLASH so I don't need to add U-boot into the ISO every time but I haven't got that working just yet.
carmine current
the part of the device tree handling that causes the assertion is broken
i can fix that when continuing work on the riscv port
= probably next week
vestal sapphire
ok time to make the IOMMU code pretty
hmm how would I represent something like this with libarch
note the 128 bit width
other than decomposing it into two 64-bit fields which would make the access (it's an array of this layout) annoying
serene portal
struct
vestal sapphire
turns out you are only somewhat right
you just arch::{scalar,bit}variable it away
carmine current
you probably want to use two 64 bit variables
since the access in hardware can also only happen in 64 bit
fervent zodiac
i mean you can do a 128 bit access with sse
using SSE instructions for mmio sounds like a great plan
carmine current
that is probably not even supported by the system bus
or it might work by chance but not because its architecturally supported
fervent zodiac
true
do you think that x86 systems support PCIe atomics?
because apparantly thats in the spec
carmine current
atomics sent by devices: probably yes. atomic access to BARs probably not
fervent zodiac
makes sense
carmine current
But that's a guess, I haven't looked into it
carmine current
x86 implements atomic access at the cache coherency level so it'd be surprising if the CPU transparently converted them into pcie transactions
when they target BARs
fervent zodiac
true
carmine current
leo do you want to PR the IOMMU code with passthrough?
or do you want to wait until you also have non-pt mode?
my stance is always that it's better to integrate more often
vestal sapphire
yeah I'm cleaning it up rn to open a PR
vestal sapphire
ok I'm close, all that's left is to debug my test case where I have devices behind two pci bridges
carmine current
@trim eagle btw, any VC / systemd work planned for this week?
trim eagle
Yep. Today unsure, tomorrow basically guaranteed
Wednesday is a hard no
Thursday and Friday hold options and the weekend itself might also pan out
vestal sapphire
I'll be around today, dunno about Tue
vestal sapphire
ok I'm close, all that's left is to debug my test case where I have devices behi...
ah okay I see what's happening now, the xhci controller doesn't even get picked up by xhci if it's behind two bridges?
carmine current
lsmbus?
vestal sapphire
I'll need to turn off iommu, one sec
carmine current
The kernel has some "wait for parent device to be published" logic
maybe that is broken for devices behind two bridges
vestal sapphire
yeah it doesn't even get published
carmine current
probably some issues with the mbusPublished event
vestal sapphire
yeah so the first bridge gets published, but not the second
carmine current
iirc we had a similar issue in the past
maybe that was never fixed
ah no that was a different bug (the one where the mbus sequence numbering was broken / fixed by qookie and me)
vestal sapphire
I think I see the problem
ok I can boot with it now, the lspci output is missing the second bridge tho
wait np
it doesn't work again?
broooo
carmine current
i wouldn't be surprised if the posix side of this was also broken
actually that looks fine from a first glance
vestal sapphire
ah I should also print the tree
nocturne tide
iommu doesn't sound too hard to implement, i might do it cuz it'll be nice to have for a somewhat complete dma abstraction so drivers don't have to worry about that :^)
native prairie
iommu doesn't sound too hard to implement, i might do it cuz it'll be nice to ha...
Its also nice for redirecting shitty devices to higher physical addresses
vestal sapphire
it actually is surprisingly easy once you understand how they want you to do things
I mean the idea for the DMA address space would be to map virtual addr == DMA addr
to avoid the lookup of the physical page
vestal sapphire
also nicely circumvents devices that restrict you to contiguous physical pages
nocturne tide
isn't it like paging with identity mapping?
or am i misunderstanding what you just said
i feel like that's the case
native prairie
it actually is surprisingly easy once you understand how they want you to do thi...
Can you give a tldr of how it works
vestal sapphire
no, the point is that you can pass virtual addresses to devices for DMA instead of having to resolve them to physical
nocturne tide
that... might work in userspace lol
anyway, looking up the physical address can be very cheap
so i am not too worried about that
vestal sapphire
we have a separate allocator for DMA memory anyways, so if that just sets up the mapping in the IOMMU along with mapping it into virtual memory for the server, you don't have to resolve to physical any more
vestal sapphire
anyway, looking up the physical address can be very cheap
not necessarily if you're a userspace server
nocturne tide
yeah but if you're in kernel mode
vestal sapphire
it's a syscall in managarm
nocturne tide
and you have a recursive mapping set up
it's a single memory access
to read the pte of any virtual address
vestal sapphire
then, sure, but microkernels
vestal sapphire
Can you give a tldr of how it works
that probably doesn't fit into discord messages, but I might do a writeup at some point if I remember to do it
otherwise you'll be able to just look at managarm code
nocturne tide
i want my io to be multi-gigabit capable, i hope that's not too hard to achieve with proper zero copy, properly written drivers and optimized builds
and soon i'll have perfect way to test it, other than my nvme drives
native prairie
that probably doesn't fit into discord messages, but I might do a writeup at som...
Nice
vestal sapphire
and soon i'll have perfect way to test it, other than my nvme drives
soon?
nocturne tide
i need to find a cheap, 10gbit capable network card that isn't absolute hell to write drivers for
nocturne tide
nah i want to write all my drivers myself
or rather i want native drivers
that use proper kernel apis for everything
especially if it's supposed to be able to handle a 10gbit connection
vestal sapphire
godspeed to you then
nocturne tide
i will need that, thanks
hopefully next year i have something cool to show off lol
carmine current
reminder that it would be good to PR in the KVM patches czapek
nocturne tide
god damn!!!! i keep forgetting it's a thing
anyway i will take a proper look after i am done moving
which is in a couple days
carmine current
nice
vestal sapphire
I'll work on the NVMe MSI fix tonight, I did not forget about that btw
carmine current
that's probably a small change
maybe it would also be good to compelete the pcap merge
carmine current
probably nothing crazy
nocturne tide
today is my last day packing up stuff, tomorrow is the moving day and the day after i should be able to take a good look and fix anything that might break with the npt cursor stuff
nocturne tide
and i'd also like to fix mapping user memory into the vm memory space because currently i expose some members that should probably not be public and i look up the physical address manually, maybe it is fixed by the cursor thing? idk, we'll see
carmine current
I tested the EPT code (it works) but not the NPT code
nocturne tide
btw do you have an AMD CPU?
nope, but dennis does so i'll have him test my stuff like last time
oh wasn't he supposed to test it?
carmine current
maybe i can also test it on my laptop
I also didn't implement EPT/NPT page faulting yet with the new implementation but that should only be a matter of doing Thread::asyncBlockCurrent(theVmSpace->handleFault(...));
nocturne tide
that sounds easy enough
carmine current
and once that's done, we shouldn't need to prefault anymore
nocturne tide
i will try doing that when i get back to kvm in a few days
carmine current
very nice sounds good
vestal sapphire
I added some stuff to vm-util to be able to build PCI hierarchies
- name: pci-bridge
type: pci-bridge
devices:
- name: uhci
type: uhci
- name: pci-bridge2
type: pci-bridge
devices:
- name: ehci
type: ehci
- name: pci-bridge3
type: pci-bridge
devices:
- name: xhci
type: xhci
makes testing stuff like that really convenient
the bridges fix is part of #870 now
native prairie
nah i want to write all my drivers myself
Wait are you making a microkernel as well?
blissful bluff
and you have a recursive mapping set up
But that's still a lot of page walking (?)
nocturne tide
But that's still a lot of page walking (?)
no? you can just index into a flat array to get the pte for any virtual address in the system
mild jetty
you still have pretty much the same number of implicit memory accesses though
recursive page tables allow you to get a pte in the minimum number of memory accesses possible but that number isn't one
nocturne tide
yeah but its done by the hardware, arguably much better than if you did the page walk manually in kernel code
mild jetty
yeah
one issue though is that i'm pretty sure you still need to do a manual walk if you want to support huge pages
because you need to know which table level you want to look at
nocturne tide
fair, i havent looked into that lmao
vestal sapphire
about the last comment on 870, I'm not sure that the log is a symptom of anything but the async nature of NVMe
what happens is that something gets posted in the completion queue, an MSI gets raised, and the handler then handles all entries in the completion queue that have the phase tag inverted (aka being marked completed but not yet handled)
this is a bit of a race condition, as if another CQE gets posted before/during MSI handling, it would get handled while servicing the first MSI, but another MSI would get raised for the second CQE, resulting in having no new CQEs when handling the second MSI
cinder trench
you still have pretty much the same number of implicit memory accesses though
nuh uh
vestal sapphire
what might also be a funni idea is getting a bunch of cheap NVMe drives from ebay and using them (in passthrough or just booting from them for real) for testing
I can get some used stuff for under 10 EUR/piece
cinder trench
nuh uh
once a page table level is in the tlb you can access ptes inside of it without walking the upper levels again, so you do get fewer accesses even implicitly
serene portal
@carmine current do i understand #84 correctly, managarm could only ever have 64 threads at once???
carmine current
64 runnable threads attached to the same scheduler instance, yes
but now it's 2^62 instead ;D
carmine current
yes
this didn't include blocked threads though, so i'm surprised that it even triggered
but it's good that this limitation is gone now
native prairie
lol
how do u even come up with such a limitation
hardware multitasking via gdt? 
lament grove
lmao how
You (used to) restrict a scheduler to 64 threads for what, time accounting purposes? lol
serene portal
fixed number precision
>Due to the usage of fixed-point numbers, the number of concurrently running threads is limited to (1 << 6) = 64 threads. This needs to be fixed, probably by using more bits to store the scheduler's progress.
alright, two NVMe test drives were ordered
carmine current
You (used to) restrict a scheduler to 64 threads for what, time accounting purpo...
Yes, basically. Not accounting but runtime calculations done to decide which thread gets to run
serene portal
i have a few cheap intenso nvmes
carmine current
In Managarm's scheduler, if a thread runs while n other threads want to run, the waiting threads improve their scheduling score by runtime / n
Bounding n was necessary to make this computation work in fixed point arithmetic
But now it's done in 128 bit so the limitation is gone
nocturne tide
Wait are you making a microkernel as well?
oh nah, lol of course not, im not insane :^)
carmine current
this is a bit of a race condition, as if another CQE gets posted before/during M...
But shouldn't the device suppress the IRQ if the CQ head was not advanced yet?
Sending one IRQ per CQE seems silly
If the driver didn't process the previous CQE yet
nocturne tide
i dont think the driver will raise an irq until the doorbell is rang
at least thats how xhci works
native prairie
oh nah, lol of course not, im not insane :^)
thats nice to hear
vestal sapphire
@native prairie I get this on my ThonkPad
it refuses to continue booting after this
could this be a hang?
vestal sapphire
perhaps enable trace logs in uacpi
where's that
native prairie
<@353593948523986945> I get this on my ThonkPad
btw what causes this event
vestal sapphire
booting
native prairie
i guess some thermal or battery event then
that event reads from a few EC fields
i wonder if it's the EC driver hanging
vestal sapphire
ig I can try commenting the battery stuff
native prairie
nah it's unrelated to battery i think
vestal sapphire
testing with logs ...
native prairie
can u add logs to ec.cpp as well
https://github.com/managarm/managarm/blob/master/kernel/thor/system/acpi/ec.cpp#L126 to this handler
lol u have an event that just calls fatal:
Method (_Q7F, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF
{
Fatal (0x01, 0x80010000, 0x000111B4)
}
at least we dont get this one
vestal sapphire
crisis averted, I now get almost to kmscon
native prairie
huh
native prairie
bruh
native prairie
btw does battery stuff get reported correctly?
vestal sapphire
yes
native prairie
and lid etc events
native prairie
crisis averted, I now get almost to kmscon
almost?
vestal sapphire
yeah it hangs after plainfb takes over
vestal sapphire
hmm I could try serial logging
native prairie
i wonder if its related to the hangs i was getting on my laptops
after plainfb
call this method from mangarm
suspending your laptop calls beep and blinks LEDs
serene portal
lmfao
carmine current
gotta debug shutdown somehow :^)
vestal sapphire
sanest firmware
native prairie
sound debugging
oh and shutdown sets LEDs to 0x00, which (i hope) means off
and uacpi calls this method so they should get turned off
Btw if EC is not available it falls back to SMI commands for accessing it
{Read,Write} byte from EC
wind hamlet
Yep. Today unsure, tomorrow basically guaranteed
does this include pulling my patch 
trim eagle
1238?
wind hamlet
yep
trim eagle
Yeah that’s the plan
vestal sapphire
btw does battery stuff get reported correctly?
pulled from the laptop over USB serial
carmine current
btw, we could probably try to debug Marvin's NVMe enclosure using USB passthrough
also to debug the systemd varlink issue, it would be nice to merge the pcap @vestal sapphire
vestal sapphire
I can't seem to make the IOMMU work on the thonkpad, it complains about invalid context entry (fault reason 3)
I have tried both pt (which is supported on both IOMMUs) and just mapping 8 gigs of memory (with 1 gb-pages) but still, nothing
carmine current
how do you construct the context entry?
.addressWidth = 0b001, <- is this supported by hw?
I'd assume that 4 level tables are supported
but not necessarily 3 level tables
vestal sapphire
yes both IOMMus support 39 bit addrs
the spec says you can choose anything up to the max supported num
so you can always use 2 or 3 levels if the hw supports 4
vestal sapphire
ah I misremembered, that was for a different field
wait wtf
cap is 0x[...]462 for both IOMMUs bruh?
ok going back to pt and 48 AGAW
ah I was looking at the wrong fields when checking addr width
ah I think I get further now
based the iGPU keeps working, now I get further
XHCI seems to work too
NVMe is giving me IOMMU faults
carmine current
are RMRRs mapped?
vestal sapphire
yes
carmine current
does the iommu support passthrough?
vestal sapphire
the only RMRRs are the iGPU and XHCI
pt is supported
I think my mapping of non-0 PCI buses is wrong, or my device traversal
carmine current
this is unlikely to be a problem here but
rootEntry->contextEntry = (contextPhys >> 12);
rootEntry->present = true;
this is broken
there is no atomicity or ordering guarantee here
this should use libarch
gcc may decide to swap the two lines and do individual read+writes
native prairie
btw what is RMRR
carmine current
memory region that needs to be identity mapped in the iommu
native prairie
why is that a thing?
vestal sapphire
btw what is RMRR
carmine current
for example, because devices steal memory from system RAM to use it as internal RAM
carmine current
it's part of DMAR, yes
native prairie
ah makes sense
native prairie
the only RMRRs are the iGPU and XHCI
i wonder why xhci needs to steal memory
carmine current
maybe for SMM based legacy kbd emulation
native prairie
perhaps
vestal sapphire
I wasn't calling DMA enable for the NVMe
it's still complaining about the root entry for bus 5 not being present, but the logs show that I do set it up
???????
carmine current
Why?
vestal sapphire
no clue
carmine current
I can only imagine that the rmrr setup is broken
Do you setup the tables for RMRR devices before enabling the iommu?
That should probably be done. There is no guarantee that xhci doesn't dma to the reserved range before our driver starts
vestal sapphire
Do you setup the tables for RMRR devices _before_ enabling the iommu?
yes
wtf now XHCI just doesn't work at all
okay, one rebuild later it just works both with and without the IOMMU
vestal sapphire
managarm-system
ok now I changed the bitfields to use libarch, and now I get seemingly random IOMMU faults
it varies between root table entry not present, context entry not present and reserved bits set in context entry (fault reasons 0x1, 0x2 or 0xb)
but only on real hw
carmine current
@trim eagle how do i build the varlink test?
and where is the source code of that test?
carmine current
If i have the test, I can maybe debug it in the evening
trim eagle
- '-Dtests=true'
- '-Dinstall-tests=true'
Add that to systemd-utils
Tests are in /usr/lib/systemd/tests/unit-test/ iirc
Source code is in src/test/<name-of-test. c>
@carmine current
carmine current
ah alright ty
I think we should unironically start getting systemd patches into bootstrap-managarm
It's close to working and that'll make it much easier to test
we can enable it with a kernel command line option stage2=systemd or similar
carmine current
systemd is just too big to merge it in one go
so we should merge it in a partially working state and improve
trim eagle
Alright. We can work on that tomorrow
carmine current
I did run the test and that currently fails because non-blocking connect is not implemented
I implemented that and now the test doesn't hang anymore but it fails
need to investigate why
I also wrote a few unit tests for accept() and connect() to test linux behavior
Linux's behavior is a bit unexpected imho
- Closed sockets return POLLIN | POLLOUT | POLLHUP | POLLRDHUP on Linux
- Linux can accept() sockets that are already closed
I can fix our connect() / accept() code to do the same
trim eagle
good stuff, fixing that would be good
I did find a small regression in journald, so that's more debugging later on
nocturne tide
lmao close one
it definitely looks wrong but depends on what code that is?
x86 paging this would be bad
ept/npt no idea
serene portal
it's supposed to be a mask for x86_64
nocturne tide
it's supposed to be a mask for x86_64
yeah that sounds wrong then lol
serene portal
it's also missing a zero
blissful bluff
*it's just missing a zero
blissful bluff
imagine some evil bitfield hiding somewhere in paging code and using lower 4 bits to do some mischiefs and this actually not being a mistake
serene portal
linux ass behavior
blissful bluff
imagine some evil bitfield hiding somewhere in paging code and using lower 4 bit...
one might say that no sane person would do that but anything can happen in C++ codebases
carmine current
right, that is a bug
seems that this was never used to get the address of a page, otherwise it would have broke things
(it was used to get the address of a page table but these have no PAT and global bits set)
carmine current
btw @vestal sapphire any news on IOMMU debugging?
serene portal
@carmine current btw there's a riscv meeting in a few mins if you wanna join
carmine current
I can't join today. I'll join during the next western friendly one
serene portal
kk
carmine current
Anything interesting in the meeting?
carmine current
nice, I'll merge it later
Btw i started working on IMSIC support on riscv
It works but i still need to clean it up
trim eagle
I can fix our connect() / accept() code to do the same
it might be good to get this in, together with 850, soon then
as that eases debugging'
and then I can rebase 831 to only leave the really needed stuff
vestal sapphire
btw <@182819561203040256> any news on IOMMU debugging?
I haven't look at it since our last vc
I will have time tomorrow
carmine current
Ah alright
vestal sapphire
for IOMMU debugging it would be really nice to have the kmsg logs reach back all the way to thor handoff as we discussed earlier
esp on real hw
ig I should do that first
carmine current
when do they currently start?
vestal sapphire
at or near the end of init tasks afaict
so it basically skips all the PCI enumeration for example
I might just actually rework all the eir handoff things we discussed a while back
like passing the memory map properly, having support for other properties (maybe via cpio), early logging setup, ...
trim eagle
Sounds good to me
carmine current
that's quite a detour
vestal sapphire
yeah but if it helps debugging
trim eagle
^
carmine current
then i'd suggest to first merge the in-progress IOMMU code
vestal sapphire
I'd rather keep it on a separate branch if it doesn't actually work
I have no problem rebasing it
carmine current
imho we have way too much code that is not properly integrated
KVM, systemd, pcap, ...
trim eagle
cries in systemd
vestal sapphire
oh yeah I'll take a look at the bragi stuff first then
carmine current
btw getting the log from when thor starts should be easy
trim eagle
oh yeah I'll take a look at the bragi stuff first then
Can I also suggest 863?
carmine current
and it doesn't require any changes in eir
trim eagle
Korona left some comments
trim eagle
I can fix our connect() / accept() code to do the same
Do you have time to look at this today? Maybe together with 850? Would be nice for systemd
carmine current
i can clean this up today yeah
the code that i implemented a few days ago doesn't yet handle the case where accept() returns an already hang-up socket
trim eagle
Sounds like what varlink needs. If we can get that PRed in today and maybe merge it, then I can start cleaning up what I have tomorrow for merging on Sunday
(Together with 850 of course)
I’ll post a proper stage 1 PR tomorrow
vestal sapphire
for the IOMMU code, ig making a pass over the entire thing as it is rn with cross-referencing the spec and possible NOVA code would be the best idea I have rn
I'll take a look at 863 and bragi first ig
vestal sapphire
I think I already cross-referenced with luna and that didn't really surface anything beyond the fact that I use pt while luna maps memory
carmine current
is it still random between: root table entry not present / context entry not present / working?
carmine current
btw getting the log from when thor starts should be easy
^ I tried to hack this together in 5min but it's not as simple as it sounds
I thought just initializing the buffer earlier would be enough but it is not
because the logging code sometimes needs IPIs to flush buffers and they are not available until the initgraph runs
vestal sapphire
is it still random between: root table entry not present / context entry not pre...
I think it was consistently context not present
flat path
maybe <@189059489486340096> also has an idea
What exactly is the issue?
carmine current
Leo is trying to add IOMMU support in Managarm and we're getting IOMMU faults on real hardware
due to table entries not being present when they are in fact present
The IOMMU is not cache coherent but we do use clflush
flat path
Hmm interesting
I can probably take a look sometime later, is the code in a PR or something?
carmine current
maybe Leo can push the current state of the code
native prairie
did it fix itself?
native prairie
which?
vestal sapphire
#voice-0 message
vestal sapphire
I did a bunch of stuff to debug it
vestal sapphire
yeah
carmine current
Hmmm, using frg::spans of arch::variable is not idiomatic imho
this should use regs_.subspace(offsetWhereTheFaultRecordsAre) instead
the intended use case of arch::variable is to manipulate data in RAM that is read/written by a device
the intended use case of arch::memspace is to access MMIO
vestal sapphire
the problem with subspaces is that the area might not even be mapped as the fault registers might not be on the same page as the regs
flat path
ah cool, nice that it works now
tbh i've never heard of that protected memory stuff, is that new?
vestal sapphire
I'm looking at the 1.0 spec so no
carmine current
the problem with subspaces is that the area might not even be mapped as the faul...
can't you just use a separate memspace in that case?
flat path
huh, weird
vestal sapphire
tbh i've never heard of that protected memory stuff, is that new?
luna has it too https://github.com/thomtl/Luna/blob/56e28f5d66508a8422304aa417e4b773c3f4ab31/kernel/source/drivers/iommu/intel/vt_d.cpp#L589-L598
flat path
huh
git blame on that says its a "thom_tl", idk who that is
never seen that before :^)
vestal sapphire
tbf I can't remember any commits > 2 weeks ago
carmine current
the problem with subspaces is that the area might not even be mapped as the faul...
also, if the faults regs and iotlb registers can cross page boundaries, the current mapping code is broken since it only ever maps one page
vestal sapphire
tbh idk if the spec says anything about that
given that he Page accessor probably doesn't work for this use case that's gonna be a bit annoying to deal with
if if that prob won't happen in practice I'd bet
carmine current
the current code may silently do stupid stuff if it happens though
carmine current
also, the page accessor is not used for these regions
KernelPageSpace::global().mapSingle4k(
VirtualAddr(faultRecordRegisters),
(drhd->register_base + faultRecordOffset) & ~0xFFFULL,
page_access::write, CachingMode::mmio);
faultRecords_ = frg::span{
reinterpret_cast<FaultRecordingRegister *>(uintptr_t(faultRecordRegisters) + faultRecordOffset),
(cap_ & Capability::nfr) + 1UL
};
^ this implicitly assumes that the fault record registers are on the same page as the general registers
vestal sapphire
kind of really the span setup is borked tho
the offset should be masked to be an offset into the page
carmine current
we should probably add the equivalent of this class: https://github.com/managarm/managarm/blob/master/hel/include/helix/memory.hpp#L10 to the kernel
that automatically does the mapping + offset computation
call it PhysicalWindow or similar
native prairie
btw shouldnt dma be enabled before bus master?
vestal sapphire
not sure
but I would think the the device shouldn't do any DMA transfer unless the driver sets up some memes?
native prairie
probably, but isnt it safer to do it the other way around anyway
carmine current
the device can definitely do DMA to RMRRs
but it shouldn't do random DMA
the order of busmaster enable + IOMMU enable shouldn't matter for correctly behaving devices
malicious devices can simply ignore busmaster enable
vestal sapphire
we should probably add the equivalent of this class: <https://github.com/managar...
should such a thing allocate virtual memory space itself?
carmine current
yes
it should own the virtual memory and release it in the destructor (after unmapping everything)
another question is: should enableBusmaster + enableDma be the same request?
vestal sapphire
hmm I did not think about that originally
the enableDma request should maybe also take an argument for configuring it, like pt or page mapping etc
carmine current
maybe that won't make sense anymore when we pass a non-passthrough DMA space (?)
vestal sapphire
dunno how nice that would be if that gets folded into busmaster
carmine current
for now it seems fine to use enableDma() for PT
native prairie
maybe enablebusmaster should be called something else then the two can be combined
carmine current
when we have DMA spaces, it should be changed to enableDma(HelHandle dmaSpace)
once DMA spaces are properly supported, we probably want to forbid DMA passthrough
vestal sapphire
hmm how would I model the array of fault record registers for libarch?
setting up an appropriately sized mem_space is unproblematic
carmine current
what's the issue?
one thing that you can do is generate the register addresses dynamically if you want to
not sure if that answers the question or not
forest bear
it's love2d iirc
native prairie
It appears to be a C++ framework with lua for scripting
Ah damn
native prairie
fast silo
yo
odd schooner
noice
vestal sapphire
we're debugging managarm by looking at a dump of requests in wireshark now
it's hella based
native prairie
very nice
fervent zodiac
so cool
trim eagle
vestal sapphire
BASED
nocturne tide
serene portal
forest bear
degraded
vestal sapphire
jaunty charm
upstream when?
trim eagle
It’s in progress. Pretty sure the Managarm side is done, mlibc almost done and there is a draft bootstrap PR with the patches
I’ll be posting systemd support for Weston tonight
Hopefully same for kmscon
jaunty charm
Oh damn that's awesome
native prairie
It’s in progress. Pretty sure the Managarm side is done, mlibc almost done and t...
Does this mean proper shutdown support as well
trim eagle
Wellllll
If systemd would just call reboot
But I had some issues when I last tried that
carmine current
Shutdown requires a bit more plumbing in the disk driver
but yes, that'll probably follow in the near future
In particular, remount as read-only needs to be implemented
trim eagle
Outside of that, executing shutdown gave some memes
trim eagle
Ah right
reef steeple
It's honestly pretty sad to see systemd think managarm is a tainted kernel
But I mean it's Linux only software
trim eagle
unmerged-bin fuck systemd on that, old kernel, yeah sure we report 0.0.1 as version
reef steeple
Is there any chance of this being upstreamed? Did you talk it out with the systemd people?
wild stone
unmerged-bin fuck systemd on that, old kernel, yeah sure we report 0.0.1 as vers...
Report 10.0.0 instead since managarm is obviously superior
trim eagle
Is there any chance of this being upstreamed? Did you talk it out with the syste...
Historical precedent says unlikely. But no there has not been any contact with systemd about this
reef steeple
I'd imagine they would be hesitant yeah
Buy pottering a beer next fosdem, warm him up
wind hamlet
I mean there's some musl changes recently merged
so I think systemd is slowly warming to the idea of at least mlibc support, managarm would probably take way more convincing
carmine current
Were there musl patches merged to systemd?
quaint fern
the systemd port is remarkable work
i haven't looked at what sort of patches you are relying on
unless they are minimal and certainly don't introduce ifdefs around managarm/mlibc then the chances of upstreaming are slimmer than victoria beckham
serene portal
unless they are minimal and certainly don't introduce ifdefs around managarm/mli...
they are bound to do that
trim eagle
unless they are minimal and certainly don't introduce ifdefs around managarm/mli...
Hahahahahahahahaha no
carmine current
IMO the patches are quite tame but upstreaming them doesn't make sense
they look fairly well maintainable though, it's not that many changes
also, they can probably be reduced by 50% by implementing things that make sense regardless of systemd
trim eagle
Yep
reef steeple
I mean there's some musl changes recently merged
thats not neaaaaaaaaaaaaaaaaaaaaarly the same as OS support, but managarm is just linux, so maybe now that much OS support is needed, and its only mlibc
serene portal
atp just configure gcc to builtin_define ("__linux__")
vestal sapphire
also, they can probably be reduced by 50% by implementing things that make sense...
the split feels like 40 % mount stuff (fixable), 30 % capability stuff (fixable), and 30 % misc (most of which is fixable, too, like loopback)
trim eagle
unless they are minimal and certainly don't introduce ifdefs around managarm/mli...
Wanted to respond earlier, didn’t do. Most of the patchwork that I did is in fact ifdeffing out stuff that I don’t care about or that we don’t implement yet. And the patches to unit files are absolutely not upstreamable. There’s a patch to add parse_printf_format which we should implement in mlibc and then drop it, a bunch of missing syscalls are stubbed so that ain’t happening (but maybe they’ll allow our patches if it’s a proper implementation for it). Some missing includes probably can be upstreamed
trim eagle
the split feels like 40 % mount stuff (fixable), 30 % capability stuff (fixable)...
Mount stuff yes, the security stuff (it’s more than just capabilities) depends if we want it and will be a lot of work but on paper yes, and the miscellaneous stuff for the most part yes on that too. Still leaves the unit files (local stuff unless we implement whatever that needs too, anyone wants to do OOMAdjust?) and the syscalls stuff
vestal sapphire
korona said that we should prob just implement posix caps and then just mostly not care
which I think is a good idea
btw libcap 1.2.74 and later fix one patch we have (because I upstreamed it ), whoever wants a free commit is welcome
trim eagle
korona said that we should prob just implement posix caps and then just mostly n...
Works for me. Doesn’t eliminate all the things tho
Some sandboxing shit and securebits BS still stands after that
Probably more but I’d need to check source code
carmine current
Capability related stuff is the least interesting imho
But stuff like mounts / bind mounts / etc should definitely be implemented
@vestal sapphire btw it would be nice to clean up the mount PR and move the device ID to the superblock etc
I want to fix missing stat() implementations (primarily to reduce log spam :^) and that would also make that easier
trim eagle
I like that, dropping patches and improving correctness
vestal sapphire
<@182819561203040256> btw it would be nice to clean up the mount PR and move the...
I'll so that tomorrow probably
trim eagle
kmscon now also works, additional fixes to dbus and weston have been made so that should work better too now
trim eagle
bonus, dhcpcd autolaunch over systemd is a thing now
trim eagle
that's a you project (but yes)
carmine current
we should just use networkd to remove the need for dhcpcd
vestal sapphire
ok I should probably update my TODO file I had somewhere at some point
this is getting a bit out of hand, I can't remember even 20 % of the stuff I wanted to fix
trim eagle
vestal sapphire
korona getting trolled today
trim eagle
again>
vestal sapphire
it doesn't matter anyways, I have comments
vestal sapphire
funny thing just happened
with some systemd bugfixes and improvements the boot time to weston has gone down significantly
I have no idea why but I'll take that W
carmine current
nice
trim eagle
Related: I timed WebKit launching into discord homepage from zero. Like 11 seconds and change measured from enter to loading bar complete
We do leak memory out the ass while running WebKit tho
So that must be investigated and fixed
vestal sapphire
too long no updates
vestal sapphire
vestal sapphire
btw notice the login timestamp?
vestal sapphire
yeah that works now with the timestamping changes
trim eagle
As I’m messing with logind
vestal sapphire
pull upstream
trim eagle
yeah that works now with the timestamping changes <:letsgo:1282155513156468747>
Let’s go
trim eagle
pull upstream
I have that. Logind just overrides it
Well
Logind and Pam
Debugging for that on Tuesdays menu
lament grove
2025 year of the Managarm desktop?
Good work, cool to see that systemd is slowly improving
I'm still working on filesystem refactors to BadgerOS but it looks like that'll be done soon™️ so I may be able to get you guys the FAT implementation too.
lament grove
I heard something like that
Well I'm not new to refactoring messes, I just need to understand how the interfaces are supposed to work in order to do such a thing
I had a bit of a look back when I originally offered to do this but not complete enough a look to actually do anything
trim eagle
2025 year of the Managarm desktop? <:trl:829316641191886888>
Logind is next, if that works reliably then yeah we might get something. Or, I might just ignore login, and go straight to KDE….
vestal sapphire
Well I'm not new to refactoring messes, I just need to understand how the interf...
Qookie is currently fixing libblockfs, and once that is done adding file systems to managarm becomes feasible
I, for my part, plan on doing btrfs at some point
I had a btrfs FUSE PoC a few years ago
lament grove
I, for my part, plan on doing btrfs at some point
ooo fancy
blissful bluff
nyanyaNyaux
vestal sapphire
but that doesn't look like alacritty, so I can't approve 😔
we already had alacritty before bruh
vestal sapphire
(it bitrotted away)
but having wezterm means it's probably not much work to bring it back up again
another update, I've been working on getting coredumps on managarm
so far, so good
trim eagle
but having wezterm means it's probably not much work to bring it back up again
Likely. I can retry it later today for funnies
vestal sapphire
getting there
vestal sapphire
ez fix
trim eagle
Nice
dusk solstice
waow
dusk crystal
Nice
vestal sapphire
one thing that's kinda annoying about this is that the I/O perf (more like the lack thereof) is really friggin bad
just writing out a few megs take multiple seconds for some reason
I wonder if for this case it might be better to have a write function that just takes a handle to a memory view
just to avoid helix_ng::sendBuffer for multi-megabyte buffers
carmine current
Hmm, probably
you could also check if mapping the output file and memcpying to it is faster
vestal sapphire
we don't really have msync implemented tho
carmine current
Mappings are scheduled for writeback when they are unmapped
vestal sapphire
ah
vestal sapphire
hmm I'm getting weird errors
including funnies like nullptr derefs in helix Dispatcher wait
idk what's wrong
is what I do rn
carmine current
Hm?
mapFile maps into the target process not into posix
Or am i misunderstanding what you're trying to do?
vestal sapphire
oh bruh
vestal sapphire
ok I still can't really make it work, it's being weird
I basically just get this when the File shared_ptr gets dropped:
In function readSectors, file ../../../src/managarm/drivers/libblockfs/src/gpt.cpp:76: Assertion 'sector + count <= _numSectors' failed!
thor: Illegal POSIX request type 38
HEL_CHECK failed: recv_resp.error()
In file ../../../src/mlibc/sysdeps/managarm/generic/fork-exec.cpp on line 434
End of lane
thor: Panic in server /usr/bin/virtio-block
gdb is being very much not helpful here
carmine current
That code path needs proper error handling
vestal sapphire
This shouldn't really happen here tho?
vestal sapphire
tldr: it's trying to write 8 sectors starting with the last sector fot the partition
root
of
all
evil
I hate imaging shit
carmine current
From where is it trying to do that? What's the stack trace inside libblockfs?
vestal sapphire
can't tell because it's garbage
#5 0x00007fffffc442b2 in blockfs::gpt::Partition::readSectors (this=0x7fffff2bf4b8, sector=<optimized out>, buffer=<optimized out>, count=1)
at ../../../src/managarm/drivers/libblockfs/src/gpt.cpp:78
#6 0x00007fffffc56291 in blockfs::ext2fs::FileSystem::readDataBlocks (this=<optimized out>, inode=..., offset=<optimized out>,
num_blocks=<optimized out>, buffer=<optimized out>) at ../../../src/managarm/drivers/libblockfs/src/ext2fs.cpp:1324
that's the only relevant part in the bt
probably from ext2fs.cpp:885
carmine current
If this comes from readDataBlocks then this happens while it tries to read from a file/dir/etc
Then the question is: why does a file point to a block outside the disk image?
@upbeat smelt btw what about the libblockfs refactoring? :^)
upbeat smelt
:^)
carmine current
Do you think you'll have some time to work on this in the near future?
upbeat smelt
the easter break is coming up
i do also have a project due but a little work on managarm can't hurt :^)
after that there's also a break at the start of may due to constitution day etc
carmine current
Nice
vestal sapphire
could it be that the issue is that ext2's truncate only updates the inode's size, and then readSector tries to read blocks that are just garbage?
I'm really not certain that that's whats happening but it makes sense
afaict we don't really support sparse files?
hmm ig what's also sus is that the meme happens for the first block that is in the double indirection block
am I tripping or is this not actually walking two indirections, but one?
cc @upbeat smelt (sorry you got git blame'd)
upbeat smelt
inode->indirectOrder2 is a different memory object from inode->indirectOrder1
vestal sapphire
sure but what level is that exactly
upbeat smelt
doubly indirect
vestal sapphire
so the 2nd (final) level laid out linearly?
upbeat smelt
manageIndirect does the load from order 1 to fill order 2
vestal sapphire
my brain hurts
upbeat smelt
the indirectOrder1 object represents 3 blocks
block 0 is the singly indirect list, block 1 is the doubly indirect list, block 2 is the triply indirect list
indirectOrder2 represents all the blocks pointed to by indirectOrder1 (starting from block 1 to skip the singly indirect blocks)
the indirection is handled in handleIndirect https://github.com/managarm/managarm/blob/baa48db3baba253603f23141736b767cfabb91ac/drivers/libblockfs/src/ext2fs.cpp#L926-L956
upbeat smelt
am I tripping or is this not actually walking two indirections, but one?
if we didn't do that right, it'd be pretty noticeable since offsets above 2MB (?) in files would be broken
vestal sapphire
yes
upbeat smelt
and i'm quite sure binaries for webkitgtk are larger than that :^) (disregarding debug info etc)
vestal sapphire
hmm it seems to be that the block pointers read from the doubly indirect stuff are garbage tho
the setup is this: I create a new file, write ~1000 bytes, truncate to ~9 MiB
then I mmap it
vestal sapphire
I wish I knew
upbeat smelt
if you look in FileSystem::write
upbeat smelt
if you look in `FileSystem::write`
or well maybe Inode::link is a better example
vestal sapphire
the diff between new size and old size if that's positive?
upbeat smelt
hm technically i think what we could do for truncate is fill the block lists with 0s
to make sparse files
also as a side note, does manageFileData actually handle sparse regions in files correctly on writeback?
writeDataBlocks depends on the blocks to be already allocated
cc @carmine current ^
upbeat smelt
the diff between new size and old size if that's positive?
yeah if the file is extended, just do what's done in FileSystem::write
substituting offset for old size and length for new size - old size ig
vestal sapphire
if(size > oldsize) {
size_t diff = size - oldsize;
auto blockOffset = (oldsize & ~(blockSize - 1)) >> blockShift;
auto blockCount = ((oldsize & (blockSize - 1)) + diff + (blockSize - 1)) >> blockShift;
co_await inode->fs.assignDataBlocks(inode, blockOffset, blockCount);
}
think that's right yeah
upbeat smelt
the synchronization is already there since that's common for extending and shrinking
vestal sapphire
ok
upbeat smelt
hmm truncate also doesn't free the blocks when shrinking :^)
so making a big file, and truncating down leaks blocks
vestal sapphire
apparently calling truncate with about 9MiB takes over 10 sec to complete????????????
vestal sapphire
probably because that makes it allocate a bazillion blocks and writing all of that out takes a while ig
idk
vestal sapphire
yeah the allocBlock calls for every single block take significant time
the fact that it writes block group descriptors for every block alloc and locks memory views quite a lot doesn't help
carmine current
Sounds like something we could optimize, yeah
carmine current
the allocation algorithm is also just very stupid
Instead of linearly searching through all block groups, we should try to allocate from the block group that contains the inode
The block allocation algorithm attempts to allocate data blocks in the same block group as the inode which contains them.
that's what the "spec" suggests at least
Also, inside each BG we can do better than linear search
maybe we can do cyclic linear search for example
So we store the block b that we allocated last and instead of iterating from 0 to N (where N = number of blocks per BG), we iterate from b to N, then from 0 to b
Actually, do we correctly zero the new blocks on truncation / write etc?
vestal sapphire
Not in upstream
carmine current
did you change it locally?
vestal sapphire
Yes
upbeat smelt
@carmine current did you see my question?
afaics the handleFileData writeback path is missing assignDataBlocks but maybe i'm missing something
carmine current
If sparse files are allowed on ext2, that's true, yes
trim eagle
Nice
vestal sapphire
I have to split it into 3 PRs tho 
carmine current
nice
today i might also join VC
or tomorrow
I caught a cold and was not feeling well for the last few days but now it's getting better
trim eagle
I have to split it into 3 PRs tho <:sadmeme:659848285510565907>
Bruh
trim eagle
I caught a cold and was not feeling well for the last few days but now it's gett...
That’s good to hear
vestal sapphire
I caught a cold and was not feeling well for the last few days but now it's gett...
just catch a warm
carmine current
vestal sapphire
I'll do the LLVM PR first today, and after that I'll try to get posix timers done
after that idk
trim eagle
I’ll be back in VC after Easter
vestal sapphire
FUCK I need to write a preprocessor test?
well time to figure out how they do that
carmine current
hopefully the llvm triple can go in quickly
vestal sapphire
I think I have the comments figured out
vestal sapphire
ok let's see if we can get the triple in before MaskRay goes offline
wild stone
just catch a warm <:meme:575445094589661215>
How would one catch a warm
Take a aspirin?
trim eagle
Alcohol
vestal sapphire
@serene portal how cursed would it be to analyse ext2 images in 010?
serene portal
<@173337436989030401> how cursed would it be to analyse ext2 images in 010?
you can already do it iirc
there are templates for a bunch of FSes
but maybe i can write a template if there isn't any
vestal sapphire
I can debug servers properly now
some things are unimplemented or scuffed but this is pretty neat
cc @trim eagle
you missed out on this
carmine current
very nice, that's quite cool
native prairie
damn
serene portal
yes bro
serene portal
trim eagle
Celebration by actually joining a VC this evening
lament grove
vestal sapphire
because we have a separate gcc with separate headers
we use freestanding libstdc++ in the kernel
blissful bluff
interesting solution...
mild jetty
can't you just do --disable-hosted-libstdcxx with the regular triplet?
vestal sapphire
which requires a separate gcc toolchain build, and we want auto-detection for that without having to supply -gcc-toolchain every time
blissful bluff
I (in my kernel) just reimplemented the containers I wanted and use the same triple for everything
vestal sapphire
there's probably more to it than that even, as we had that setup before the freestanding libstdc++ stuff
I'm not sure what it would take to build the kernel with the regular triplet
that might not even be that bad of an idea if that solves our upstreaming problems with that
I'll put it onto my TODO list, ig we'll see how horrible of a hack that'll turn out to be
blissful bluff
Can't you just complile freestanding libstdc++ separately?
vestal sapphire
no idea
the LLVM patch adds no real logic
we will have to keep the kernel gcc around tho
I don't think we can beat the regular system-gcc into submission to cover that
mild jetty
the difference between managarm-kernel.h and managarm-mlibc.h seems like it'd be covered by -nolibc -nostartfiles
the thread_file stuff can be done the same way linux does it: case ${enable_threads} in "" | yes | posix) thread_file='posix' ;; esac
you can use t-slibgcc unconditionally and disable it when building the kernel compiler with --disable-shared
dusk crystal
Nice
vestal sapphire
I have gotten nvidia modesetting working on my RTX2070
the driver should just work with every card with a GSP, that is 1600 series and later
odd schooner
nice!
upbeat smelt
congrats, very nice
trim eagle
YOOOOOOOO
bold knot
I have gotten nvidia modesetting working on my RTX2070
this is unfathomably based
native prairie
I have gotten nvidia modesetting working on my RTX2070
Damn wtf
Is this with your driver or the managarm port
vestal sapphire
The port of NVIDIA's open kernel modules
spring oak
how hard is to port those?
native prairie
The port of NVIDIA's open kernel modules
Does that mean you figured out the semaphore bug
vestal sapphire
You need to have quite some infra in place for it to work
spring oak
f
vestal sapphire
Does that mean you figured out the semaphore bug
Oh yeah, it was a combo of stupid skill issues
native prairie
sounds dangerously close
vestal sapphire
I mean I can just reuse shit that's already built
What could hurt a bit of if it wants more sysdeps
Esp things like fence fds
native prairie
yeah thats annoying
vestal sapphire
I want to upstream a minimal modesetting driver first anyways so that'll go first
quaint fern
I have gotten nvidia modesetting working on my RTX2070
this is remarkable achievement
storm plover
I have gotten nvidia modesetting working on my RTX2070
Impressive!
dusk solstice
damn that's amazing
full slate
I have gotten nvidia modesetting working on my RTX2070
phoronix article when
shrewd grove
I have gotten nvidia modesetting working on my RTX2070
very nice 🎉
serene portal
phoronix article when
this
native prairie
yeah this deserves some sort of a news article
kind seal
Larabel did two articles about my OS many years ago, and without anything as neat.
lament grove
I have gotten nvidia modesetting working on my RTX2070
vestal sapphire
yeah this deserves some sort of a news article
Yeah let me merge this first
serene portal
yea and maybe show that it works on other gpus
sudden glen
i can test on a rtx 4060 if needed
spring oak
i can do on a rtx 2070 super
vestal sapphire
I'll continue working in this tonight
vestal sapphire
For some reason it performs a full modeset on every page flip
I need to fix that and wire up some minor stuff
I'm having my coffee rn and after that we ball
vestal sapphire
so I tried to implement /dev/nvidiactl a bit and I got as far as having it actually pass through ioctls to NVRM
however now it wants me to memcpy to a user process
basically like linux copy_from_user
how do we do that lol
https://gist.github.com/mtijanic/32b077542b7e56dc603074115fcaea75 is what I'm trying to get working
I mean I could imbueCredentials for the ioctl
but how do I have the server obtain the userspace process' address space handle
upbeat smelt
it doesn't
vestal sapphire
how do we make it get that tho
we need that for NVRM ioctls
which we need for 3d accel
nocturne tide
vestal sapphire
I have NVRM ioctls working
nocturne tide
@\qwinci nvidia-smi + mlibc glibc compat 
trim eagle
Based
carmine current
re copy from user: #678613590646849576 message
vestal sapphire
Already solved on stream with czapek
carmine current
which strategy did you pick?
storm plover
YOOOOOOOOOOOO IT WORKS
cedar cosmos
how do we do that lol
I'd do it by changing cr3 to the user process' address space and have a fault tolerant copy
how hard is it in this context?
(of course you need to guard against thread out schedules changing the cr3 back)
brittle mauve
I'd do it by changing cr3 to the user process' address space and have a fault to...
the driver itself is in an userspace process so you can't really do that
cedar cosmos
Wait
Oh
Managarm
Yeah well you'd need to introduce facilities to write to another process' VM, or have some other way to communicate this data
If anything you'd want to first write to a buffer within your own driver and then transmit this data to the user process
Perhaps
A thing that could be useful is the ability to map a slice of a process' address space into your own
carmine current
Yeah well you'd need to introduce facilities to write to another process' VM, or...
the main problems is making this secure and fast
drivers do not have handles to the virtual memory spaces of applications, so they cannot directly do this
they either have to ask the posix server that owns the application or find some other way (such as telling the application to do the write)
nocturne tide
or they get a handle to the process' virtual memory through ipc 
which is what we did with leo yesterday
though i am not sure that's the best solution
vestal sapphire
how are you so fast
well it isn't 3d accel yet, just the program that changes NVRM's logging verbosity
so I prob will need a few more sysdeps
and prob some other bs too
but at least I have /dev/nvidiactl
so in theory you should be able to run some utilities now
problem is that nvidia-utils does not have public sources