freakazoid333 has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
terrorjack has quit [Read error: Connection reset by peer]
terrorjack has joined #osdev
freakazoid333 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
smeso has quit [Quit: smeso]
ZetItUp has quit []
smeso has joined #osdev
ElectronApps has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
mctpyt has quit [Ping timeout: 256 seconds]
mctpyt has joined #osdev
wgrant has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
dormito has quit [Ping timeout: 255 seconds]
dormito has joined #osdev
terrorjack has quit [Read error: Connection reset by peer]
terrorjack has joined #osdev
freakazoid333 has quit [Read error: Connection reset by peer]
freakazoid333 has joined #osdev
ElectronApps has quit [Remote host closed the connection]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
vdamewood has joined #osdev
ElectronApps has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
night has quit [Read error: Connection reset by peer]
night has joined #osdev
terrorjack has quit [Remote host closed the connection]
terrorjack has joined #osdev
wgrant has quit [Quit: WeeChat 2.8]
wgrant has joined #osdev
tacco has joined #osdev
tacco has quit []
SGautam has quit [Ping timeout: 250 seconds]
ElectronApps has quit [Read error: Connection reset by peer]
ElectronApps has joined #osdev
flx- has quit [Quit: Leaving]
flx has joined #osdev
mhall has joined #osdev
dennis95 has joined #osdev
ElectronApps has quit [Ping timeout: 265 seconds]
<sahibatko>
Hi, I think there was a discussion on the forum/wiki about when it is better to update CR3 (invalidate whole TLB) and when to call a batch of INVLPGs - cannot find it now, any hints?
sortie has joined #osdev
SGautam has joined #osdev
mctpyt has quit [Ping timeout: 265 seconds]
nyah has joined #osdev
mctpyt has joined #osdev
freakazoid333 has quit [Read error: Connection reset by peer]
GeDaMo has joined #osdev
dormito has quit [Ping timeout: 252 seconds]
alexander has quit [Ping timeout: 265 seconds]
alexander has joined #osdev
vdamewood has joined #osdev
vdamewood has quit [Ping timeout: 240 seconds]
vdamewood has joined #osdev
dormito has joined #osdev
<sortie>
I published my ports of perl and texinfo :)
<sortie>
In other words
<sortie>
I'M NOW FULLY SELF-HOSTING, like officially, WITH ALL THE PORTS
<sortie>
I even have a nightly VM running that builds today's source code and ports completely natively
<dzwdz>
congrats!
iorem has joined #osdev
ElectronApps has joined #osdev
<mjg>
sortie: w00t
aleamb has quit [Quit: bye]
SGautam_ has joined #osdev
SGautam has quit [Ping timeout: 256 seconds]
<dzwdz>
sortie: oh, i've just realized that you're behind sortix - what's that #port5742 thing?
<dzwdz>
i found it when browsing through libera channels, i tried ncating to it but i couldn't do anything
SGautam_ has quit [Remote host closed the connection]
pg12 has quit [Ping timeout: 268 seconds]
<sortie>
Thanks dzwdz and mjg :)
<sortie>
dzwdz, ah it's a PUZZLE
pg12 has joined #osdev
<dzwdz>
is looking at the source cheating?
<sortie>
What's that, a mysterious TCP port? Sending back mysterious data when you send it mysterious data?
<sortie>
dzwdz, no -- cuz' the source is not published
<dzwdz>
ah
<dzwdz>
can i join the channel before i've figured it out?
<dzwdz>
or does it have spoilers
<sortie>
No spoilers at this time (mostly spoilers happen when other people are also solving it in there)
<sortie>
Do join and let me know if you solve it :) Then we can interoperate
isaacwoods has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ahalaney has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
ElectronApps has quit [Remote host closed the connection]
ElectronApps has quit [Read error: Connection reset by peer]
ElectronApps has joined #osdev
johnjay has joined #osdev
srjek has joined #osdev
johnjay has quit [Ping timeout: 268 seconds]
johnjay has joined #osdev
kingoffrance has quit [Ping timeout: 255 seconds]
ElectronApps has quit [Ping timeout: 268 seconds]
divine has joined #osdev
iorem has quit [Quit: Connection closed]
catern has joined #osdev
dutch has quit [Quit: WeeChat 3.2]
dutch has joined #osdev
Optimus has joined #osdev
Celelibi has quit [Ping timeout: 256 seconds]
Celelibi has joined #osdev
archenoth has joined #osdev
Optimus has quit [Ping timeout: 252 seconds]
Optimus has joined #osdev
Oshawott has quit [Ping timeout: 252 seconds]
Oshawott has joined #osdev
archenoth has quit [Ping timeout: 252 seconds]
Izem has joined #osdev
puck has quit [Remote host closed the connection]
puck has joined #osdev
Izem has quit [Quit: Konversation terminated!]
Optimus has quit []
ahalaney has quit [Remote host closed the connection]
ahalaney has joined #osdev
flx has joined #osdev
puck has quit [Ping timeout: 252 seconds]
puck has joined #osdev
kwilczynski has joined #osdev
CompanionCube has quit [Ping timeout: 252 seconds]
kingoffrance has joined #osdev
<geist>
riscv emulator as BPF style VM, discuss
<dzwdz>
isn't bpf meant to always terminate?
<dzwdz>
it doesn't even have backwards jumps, right?
<geist>
probably?
<geist>
dunno!
<moon-child>
eh just suspend it periodically
<geist>
yah. someone was doing something like that at work and it kinda makes a sense. RV itself may be overkill for that style, but there's a lot of compiler support for it, etc
<bslsk05>
www.kernel.org: Linux Socket Filtering aka Berkeley Packet Filter (BPF) — The Linux Kernel documentation
<geist>
and a simple rv32 emulator is pretty tiny, easily within 1K of code
<moon-child>
wasm is thattaways too
<geist>
so seems you could fairly easily just blat out little programs and emit RV32, even spool up an emulator in essentially zero time
<geist>
but yeah you could also do something like 'you get N instructions to do your task' and then stop the emulator
<jimbzy>
Yeah, but why would someone want to write their own OS? XD
<jimbzy>
Sorry. I'm just excited to have a a month off before classes resume.
<geist>
yay month off
<geist>
i'm guessing your plan is to do jack squat?
<geist>
or the plan is to do a bunch but the result is jack squat?
<kazinsal>
that was the end result of my week off a couple months ago
<kazinsal>
was 100% sure I'd end up having my project be at least somewhat "production ready" but uh, nah, I ended up just refactoring some of the build system and then playing a bunch of FF14
<geist>
yah, i recently got occupied wih the last EA jedi game. kinda mindless but fun
<jimbzy>
geist, I have a few projects around the house to keep me busy, and I can drive a cab if I get bored.
<kazinsal>
part of me wanted to try doing uber in my BRZ as a lark but they were like NO YOU MUST HAVE FOUR DOORS
GeDaMo has quit [Quit: Leaving.]
zoey has quit [Quit: Leaving]
<jimbzy>
I thought about going that route, but then my neighbor introduced me to the owner of a local company so I use their rides instead.
dutch has quit [Quit: WeeChat 3.2]
dutch has joined #osdev
gog has joined #osdev
dormito has quit [Ping timeout: 245 seconds]
<gog>
mew
* moon-child
pets god
<dzwdz>
which one?
dennis95 has quit [Quit: Leaving]
<jimbzy>
All of them.
<gog>
not sure which one i am
* geist
stomps through the city with a sailor hat
<kazinsal>
geist has completed his transformation into popeye
mcfrdy has quit [Ping timeout: 252 seconds]
mcfrdy has joined #osdev
Belxjander has quit [Ping timeout: 252 seconds]
ZipCPU has quit [Ping timeout: 252 seconds]
dh` has quit [Ping timeout: 252 seconds]
dzwdz has quit [Ping timeout: 252 seconds]
dzwdz has joined #osdev
dormito has joined #osdev
jjuran_ has joined #osdev
brenns101 has joined #osdev
ahalaney has quit [Remote host closed the connection]
jjuran has quit [Read error: Connection reset by peer]
rorx has quit [Read error: Connection reset by peer]
sahibatko has quit [Ping timeout: 265 seconds]
jjuran_ is now known as jjuran
brenns10 has quit [Ping timeout: 265 seconds]
brenns101 is now known as brenns10
rorx has joined #osdev
johnjay has quit [Ping timeout: 252 seconds]
<jimbzy>
gog, Crepitus?
<gog>
lol
superleaf1995 has joined #osdev
<superleaf1995>
i've been thinking of a way to allocate pci devices
<geist>
are you going to stick around for an answer?
<superleaf1995>
however i would like to know some stuff - do pci devices can have their BAR sizes changed?
<superleaf1995>
like for example can a pci device change bar size after being configured?
<geist>
perhaps if they're reset?
<superleaf1995>
i would like to know if such thing is even possible (i don't think so but who knows :U); and also, can pci devices have bars removed/added dynamically after configuraaa-
<superleaf1995>
wait so that means it
<superleaf1995>
ok ok so bar sizes can change after reset seems horrible but ok
<geist>
i dunno, its not an authoritative answer
<geist>
but seems like if it tries to change dynamically it'd be difficult
<geist>
without some sort of implementation specific solution i guess
<geist>
but really you should stick around more than 2 minutes in case someone more versed comes along
<geist>
(hint hint)
<superleaf1995>
yes, sorry :P
<superleaf1995>
i mean i really want to know what PCI can and can't do so i can make my allocator be as robust as possible
<geist>
also you used to be superleaf1994?
<superleaf1995>
no?
<geist>
ah okay. someone said the other day but guess that wasn't true
<moon-child>
yeah I grepped my irclogs and couldn't find any superleaf1994s
<moon-child>
i don't know why i thought that
<geist>
anyway i suspect that in normal uses no the device must ask for hwat it wants, at least after it's reset
<geist>
of course thunderbolt or any sort of hot plug pci throws a wrench in
<superleaf1995>
yeah that is my main concern
<geist>
there's some new featre in nvidia to ask for large BARS on the 3000 series stuff? has anyone observed that?
<superleaf1995>
i want my pci allocator to not break when someone decides to remove half the pc
<geist>
also dunno how that works, is it a firmware thing that asks for a huge bar or is if some negotiation with the driver that somehow causes a new BAR to come into existance
<kc8apf>
BARs are generally read-write all the time. Changing them will require both sides to be in agreement about what is going to happen.
<superleaf1995>
i've heard certain types of pci buses do not support hotplug even when their children does
<superleaf1995>
however the main concern is that the posibility of a device going out of it's way and dynamically deciding to realloc_bar
<kc8apf>
hotplug is many things depending on what era of PCI you're talking about and whether eletrical or software
<geist>
kc8apf: yah that's what i assume. dunno if it's *legal* but i guess if both sides agree then its a possibility
<superleaf1995>
kc8apf: pcie
<superleaf1995>
since pcie is mostly where hotplug goes funky
freakazoid333 has joined #osdev
<geist>
oh i doubt a dvice can decide to do anything like that on its own in any case
<superleaf1995>
In summary - my main concern is that whateever or not a device wanting to reallocate BARs is legal on PCI (since device can decide to turn on/off some bits) - the main protector against chaos is that only some devices are able to hotplug, and the children must also be hotplug, if neither of those is hotplug then no worries everything is static - however when it's hotplug i think it would be a good
<kc8apf>
in a typical PCIe hotplug surprise insertion, a device # was preallocated for the slot by the firmware. On detection of PRSNT#, firmware will probe the device and configure BARs. Address decoding for BARs can be tricky when you consider bridges so most likely the available BAR address space would have been preallocated by the firmware
<superleaf1995>
idea to reserve x4 times the size of a BAR so i could accomodate realloc
<geist>
even in a hot plug situation i dont think the device gets to decide when it go out to lunch
<kc8apf>
BARs are always programmed by the host firmware
<superleaf1995>
how realiable is firmware?
<superleaf1995>
no wait
<geist>
you're the firmware
<superleaf1995>
the thing is that my kernel is just straight up ignoring firmware and decides to do stuff for themsel
<superleaf1995>
ye
<kc8apf>
Sure, firmware can hand off to kernel
<superleaf1995>
when a surprise isnertion happens do i have to accomodate the new device in question?
<superleaf1995>
now - i've heard that reacommodating bridges may be troublesome since if you run out of allocatable space you need to reconfigure everything and some gpus really hate that
Matt|home has quit [Ping timeout: 255 seconds]
<superleaf1995>
the good thing is that this can be simply fixed by first allocating non-hotplug capable bridges in the start of the bar space and then leave the rest for dynamic allocations on hotplug - seems like it
<superleaf1995>
but if i do everything kind of right i can still reacommodate certain devices without them breaking, right?
<geist>
i dont think you get surprise insertions unless you ask for it
<superleaf1995>
well what if i ask for it
<kazinsal>
then it's not really a surprise
<geist>
i dont really know, but i *assume* that in a hot plug environment, it's firmware's job to consult the chipset and notice insertions and then go kick off the machinery to deal with it
<kazinsal>
there's probably some bizarre acpiml mechanism for it
<geist>
kinda like USB: 'i see a device on port x'. firmware then goes and powers up port x and starts enumerating
<superleaf1995>
so basically i will be asking the chipset every ms where is device
<geist>
no idea. perhaps an interrupt, etc. mechanism is probably chipset specific, but kc8apf may know more
<superleaf1995>
hmmm right
<geist>
for something like thunderbolt i'm almost certain there's a thunderbolt controller device somewhere that you have a driver for
<superleaf1995>
the "chipset" it's the pci bridge right
<geist>
that at the minimum you use to negotiate watever goes on downstream from the port
<superleaf1995>
so i just spam some msi-x stuff and it will work?
<geist>
again. i'm giving you vague notions of how it works
<geist>
do not in any way derive concrete answers from this
<superleaf1995>
gotcha
<geist>
like 'it probably works this way'
<geist>
also i may be completely full of shit
<geist>
i'm just guessing based on what is probably the sane solution for this sort of thing
<geist>
at the minimum there's a phsyical layer to deal with: some piece of software on the host needs to know that something is detected and give a go-ahead for applying power
<geist>
if nothing else simply to avoid browning out the machine, etc
<superleaf1995>
So the main plan would be first allocating non-hotplug capable devices at the start of each space, then allocate a dynamic space for hotplug devices to play with - since the way that pci works i would just need to use some form of tree to manage all of this
<geist>
plus security issues etc etc
<superleaf1995>
ah yes many security
<superleaf1995>
i dont think i can't defend against a malicious pci device; do i?
<geist>
you wouldn't want any device on the other side of any sort of hot plug to just suddenly start doing something without at least some host sofware intervention
<geist>
of ourse you can. you can simply not start it up
<geist>
(plus iommu, etc)
<superleaf1995>
ah, i see
<geist>
that's my point. i seriously doubt anything automatically works without software at least pressing the go button
<superleaf1995>
seems fair ig
<superleaf1995>
not sure the "detect malicious" part would work but i would probably come with something :P
<geist>
well all this aside i really really wouldn't worry about this
<geist>
you're going to need a whole lot more software than just your BAR allocator to be written to support any of this
<geist>
so frankly the BAR allocation is not the biggest pole in this tent
<superleaf1995>
true
janemba has quit [Read error: Connection reset by peer]
janemba has joined #osdev
superleaf1995 has quit [Quit: leaving]
iorem has joined #osdev
Oshawott has quit [Remote host closed the connection]
nur has quit [Remote host closed the connection]
Oshawott has joined #osdev
nismbu has joined #osdev
nismbu has quit [Remote host closed the connection]