<mrvn>
my mouse moved from emacs to the irc window.
<dh`>
never use rand()
<psykose>
my irc client doesn't send on newline for exactly that reason
<psykose>
been burned by that many times
<heat>
never use ranges
<heat>
nor array
<heat>
nor cout
<zid>
There's a simple abbreviation for that heat
<psykose>
never use main()
<zid>
never use anything in the C++ standard pdf
<clever>
psykose: irssi will confirm if you meant to send it, when you send a wall of text
<clever>
2022-05-28 23:04:13 -!- Irssi: Pasting 10 lines to #osdev. Press Ctrl-K if you wish to do this or Ctrl-C to cancel.
<zid>
My favourite is those clients that just send it anyway, but rate limit it so they don't get sendq'd or bot kicked
<psykose>
indeed, many clients check some form of isPasting and don't send
<clever>
zid: when mirc is rate limiting, you can /flood clear i think it was
Oshawott has quit [Read error: Connection reset by peer]
<heat>
operating systems are cringe
<heat>
i'm going into web dev
<heat>
after sinking 7 years of my life into this I've realized this is the opposite of based
<zid>
true basedness comes from doing it anyway
<zid>
based doesn't mean corporate slave desperately seeking meaning from daddy capital
<heat>
based doesn't mean designing a virtual memory system
<heat>
based means centering a div
arch_angel has joined #osdev
air has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bauen1 has quit [Ping timeout: 252 seconds]
heat has quit [Ping timeout: 244 seconds]
Likorn has quit [Quit: WeeChat 3.4.1]
Likorn has joined #osdev
<mrvn>
eat, drink and be merry for tomorrow we die
sonny has joined #osdev
<Clockface>
when i call into a C function manually from an assembly program, what happens if i put 0 in some of the argument registers if there are less than 6 arguments
<Clockface>
also, does something have to be done to the stack?
<mrvn>
your cat gets pregnant if you don't have a cat
<mrvn>
You should read the calling conventions of your architecture.
<Clockface>
i have, it dident mention anything about the stack
<Clockface>
so im assuming i dont have to do anything
<Clockface>
as for the unused argument registers, im just making sure the compiler is expecting their value to be undefined
<mrvn>
I don't think any modern cpu doesn't require some stack alignment
<mrvn>
the structure return register could be crucial
<mrvn>
I have never heard of an arch that specifies unused registers have to have some state. But beware that that also applies on function return.
<Clockface>
im excpeting every register except the base register (specified as callee saved) to get clobbered, so im not too worried
<Clockface>
im expecting more registers to get clobbered than it says are not saved, so im extra safe
<dh`>
the stack alignment does matter
<Clockface>
im also not having the manual assembly code called by anything, so i dont need it to save registers
<Clockface>
i got it, thanks
bauen1 has joined #osdev
yewscion has quit [Ping timeout: 244 seconds]
Likorn has quit [Quit: WeeChat 3.4.1]
_xor has joined #osdev
sonny has quit [Ping timeout: 252 seconds]
Teukka has quit [Read error: Connection reset by peer]
<Griwes>
I started looking at the format of .eh_frame and... oh boy. There's some dragons in there
Teukka has joined #osdev
<clever>
Clockface: usually, the ABI of most systems, is such that the first N args go into registers, and the next args go onto the stack, with arg N+1 being the first thing, and N+2 being at a higher addr
<clever>
Clockface: so if you call a function expecting 5 args, but give it 10, the extra 5 args are just at an addr it doesnt look at
<clever>
and if the caller cleans up the stack, it knows to remove all 10 elements from the stack, and repairs it just fine
<clever>
the stack frame consists of a frame pointer, which points to the middle of the frame, which is the previous frame pointer
<clever>
above the framepointer will be things like the return addr, and the extra args
<clever>
below the frame pointer is the local vars
<clever>
but gcc can also omit the framepointers, so that slot is effectively 0 bytes wide
<clever>
the frame pointer makes generating a stack trace simpler, because the stack frames form a linked list
<clever>
without a framepointer, you need to have a table that tells you the offset between SP and the framepointer, for every PC in the entire binary!
sonny has joined #osdev
bauen1 has quit [Ping timeout: 246 seconds]
bauen1 has joined #osdev
GeDaMo has joined #osdev
sonny has quit [Quit: Client closed]
the_lanetly_052_ has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
bauen1 has quit [Read error: Connection reset by peer]
bauen1 has joined #osdev
lanodan has quit [Ping timeout: 246 seconds]
lanodan has joined #osdev
bauen1 has quit [Read error: Connection reset by peer]
bauen1 has joined #osdev
nsmb has quit [Ping timeout: 246 seconds]
_xor has quit [Quit: brb]
_xor has joined #osdev
vdamewood has joined #osdev
Likorn has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 246 seconds]
bauen1 has quit [Read error: Connection reset by peer]
bauen1 has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bauen1 has quit [Read error: Connection reset by peer]
<clever>
so you can load your kernel over the network, from grub
<clever>
then you can test on real hardware, without having to reflash after every build
<mrvn>
try booting with bochs. sometimes a different emulator spots errors.
<kazinsal>
yeah grub over PXE is how I test, it's way more straightforward.
<kazinsal>
my build command is basically make clean all -> copy shit to /araxes/tftp
<zid>
-machine q35
<kazinsal>
then on the test machine I punch "reload confirm" into the console and poof, fresh TFTP boot
<kazinsal>
(if the machine is in a working state the user mode shell calls the syscall for "restart the machine right fucking now". if the machine is in a crashed state the kernel debugger does the same thing without the syscall barrier)
freakazoid333 has quit [Ping timeout: 258 seconds]
gildasio has quit [Ping timeout: 240 seconds]
gildasio has joined #osdev
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
jafarlihi has joined #osdev
<jafarlihi>
Why xv6 linker scripts mentions the output format with 3 arguments?: OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
gildasio has quit [Ping timeout: 240 seconds]
<zid>
OUTPUT_FORMAT(default, big, little)
<zid>
For example, the default linker script for the MIPS ELF target uses this command:
<bslsk05>
www.gnu.org: GNU GRUB Manual 2.06: Network
jafarlihi has quit [Ping timeout: 255 seconds]
frkazoid333 has joined #osdev
mykernel has quit [Read error: Connection reset by peer]
mykernel has joined #osdev
dennis95 has quit [Quit: Leaving]
<mykernel>
can someone share dnsmasq config for pxe
the_lanetly_052_ has joined #osdev
<zid>
they're entirely unrelated though?
<mykernel>
?
<mykernel>
Netboot directory for i386-pc created. Configure your DHCP server to point to /srv/tftp/boot/grub/i386-pc/core.0
divine has quit [Ping timeout: 248 seconds]
simpl_e has quit [Remote host closed the connection]
simpl_e has joined #osdev
bauen1 has joined #osdev
lanodan has quit [Ping timeout: 258 seconds]
lanodan has joined #osdev
heat has joined #osdev
bauen1 has quit [Read error: Connection reset by peer]
sonny has joined #osdev
mykernel has quit [Quit: leaving]
<zid>
why duke fishron so stronk
<zid>
also, not seen gog in a while did you scare her off
<psykose>
probably busy being gay, no time for mere ordinary osdev
<zid>
I wasn't aware it was such a time commitment
<psykose>
certainly is
<zid>
you're not gog are you?
<zid>
whois says no but brain says maybe
<GeDaMo>
Your brain is drunk, tell it to go home :P
<psykose>
i'm definitely not cool enough
<psykose>
but i will take that as a compliment
mahmutov has quit [Ping timeout: 255 seconds]
<zid>
how cool you are depends on what's on your pencilcase
<zid>
everybody knows that
mahmutov has joined #osdev
puck has quit [Excess Flood]
puck has joined #osdev
terminalpusher has joined #osdev
<mrvn>
"What are your super-powers again?" "I'm rich."
<sham1>
zid: duke fishron? Normal, expert or master?
<zid>
calamity technically, but normal
<zid>
he hits hard
<sham1>
ah
<zid>
maybe I should do grav hook strats
<sham1>
Do you have all your potions
<sham1>
I don't know much about calamity, but potions tend to help a lot in the base game
<zid>
I mean, ironskin's not really gunna help much when he hits for 300 :p
<zid>
Annoyingly, it's set up so the first fishron kill is the hardest because he drops good anti-fishron gear
<zid>
the mount is ludicrous, especially because calamity has a usable item that makes it start raining
<zid>
I was only fighting fishron because deux axiom was too hard, which I was trying to kill because cultists were too hard :P
<zid>
astrum deus, whatever it is
lanodan has quit [Ping timeout: 258 seconds]
Matt|home has joined #osdev
lanodan has joined #osdev
rorx has quit [Ping timeout: 258 seconds]
* geist
yawns at everyone
<geist>
heat: you there?
<geist>
you had some PCI question last night, i thought it might even be LK related?
<geist>
also hi night
<zid>
it's only 8pm, say hi evening
<geist>
i tagged night, according to irccloud
<geist>
much like how i like to say clever, because it's a nice word, but it also tags clever every time
blockhead has joined #osdev
rorx has joined #osdev
Matt|home has quit [Quit: Leaving]
netbsduser has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 260 seconds]
<heat>
geist, yup
<geist>
did you get it resolved?
<heat>
no
<heat>
i ended looking a bit at linux code but that was obviously confusing so I stopped looking at that in general
<geist>
so what was the question?
<geist>
or more importantly if you want to rephrase, please do so
<heat>
how do you know if you need to do BAR allocation
<heat>
firmware does it for you on PC (if you're not the actual firmware, that is)
<zid>
My first thought is that if the BARs aren't set up and they should be that's a quirk
<heat>
qemu's machine virt aarch64 and riscv64 seem to need BAR allocation if they're not running with UEFI firmware
<geist>
basically, if they're not set up then they need to be configured
<zid>
what about a false positive 0 or something though on a weird arch, in that case geist
<geist>
yah. so the LK code i wrote just makes a pass over them to see what's there and then goes back and starts to assign resources for things that haven't been configured
<geist>
zid: what do you mean?
<zid>
how are you detecting 'not configured'
<zid>
and how reliable even is it
<heat>
probably "all-ones and a non-zero size"
<zid>
(hardware is silly)
<heat>
for any given BAR
<geist>
bars with 0 in them, even though they have a non zero size
<geist>
also bridges that appear unconfigured
<zid>
so it's not allowed in pci-e to have a device at 0?
<geist>
sine you can't see whats on the other side of a bridge until you configure it
<zid>
hence the false positive thing
<geist>
that's correct. i remember reading precisely that
<zid>
oh okay then, fair dinkum
<geist>
0 is a sentinel for not configured
<heat>
but those BARs are all ones aren't they?
<heat>
0xffffffff
<geist>
you write all 1s to see what the size is
<geist>
because the bottom N bits will read back as zero
<heat>
"BAR4: I/O at 0xffffffffffffffff [0x001e]."
<geist>
that does mean that if you write 1s to a device to probe it there's a temporary period of time where the device is unconfigured
<geist>
er that bar
<heat>
this is from a -S'd qemu-system-x86_64
<geist>
actually fun fact: we just found a rare fuchsia bug where the kernel is using a PCI uart, and user space probes the device simultaneously
<zid>
locks on your bars? oh dear
<geist>
yeah tis the problem with microkernels: cant easily lock that
<geist>
heat: i dunno. i think they came up as 0s on arm and riscv. or maybe all ffs is also the case? lemme see
<bslsk05>
github.com: lk/bus.cpp at master · littlekernel/lk · GitHub
<geist>
and then recursively allocates stuff
<geist>
this is after assigning secondary busses for all the bridges in a precious probing path, so all the devices can be found
<geist>
but the decision to do that call is up to the platform currently. however i suppose it could try to guess whether or not it needs to assigned stuff based on what it observed during the probe pass
sonny has quit [Remote host closed the connection]
sympt has quit [Ping timeout: 246 seconds]
<eau>
hoi anybody got a good documentation/introduction on understand ACPI?
<eau>
and come back with questions if things are not clear
<zid>
It's basically just some structs, you find the first one at the end of the bios rom region
<zid>
and you walk them and they tell you things
<eau>
but what's the deal with AML etc.. ?
<zid>
and then eventually you get into the weird bytecode ones for power management
<zid>
which you can ignore unless you're doing real-hardware-laptops
arch_angel has joined #osdev
<zid>
and there are libs for it anyway if needed
<eau>
ok let me read and crawl, thx zid!
<geist>
yah key is not all of the ACPI tables require AML. the ones you use for basic configuration that kernels usually need to get going are just tables
<zid>
I have some shitty C code that parses enough to get the pci-e base address, which is the only thing I cared about
<eau>
ok
<catern>
have there ever been any CPU memory prefetchers that are integrated with the memory controller to do data-dependent prefetching? toy example: prefetching exactly and only all of a long null-terminated string by scanning for the terminator on the memory side (somehow), rather than having to do multiple roundtrips where the CPU checks the loaded bytes for a null byte then sends another read request
<moon-child>
everybody wants _their_ stuff on the memory controller :P
<moon-child>
I seem to recall a comment from a hardware person(?) about this sort of thing, saying it wasn't worthwhile. Let me see if I can find it...
<zid>
how do you teach the memory side you're doing a string
<zid>
the cpu knows it's doing a rep scas or whatever it is though, and can issue the right prefetches anyway
<catern>
zid: yeah the CPU would need to inform memory that's what it's looking for, somehow, as some new kind of memory request
<bslsk05>
'Stanford Seminar - Mostly Missless Memory in the Mill CPU' by Stanford Online (01:30:57)
<catern>
moon-child: hah yes linked list chaining was exactly the other example I was going to give!
<catern>
moon-child: alas his answer to that is not very detailed haha
<catern>
I'd love to hear more from him about those proposals...
<moon-child>
agreed
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
<zid>
yea linked list is a good example
<zid>
it's random but predictable
<zid>
if that makes sense
<mrvn>
For strings you just keep fetching cachelines.
<mrvn>
But for linked list, or more general pointers it could be cool to say: Give me the pointer and pre-fretch what it points to
<mrvn>
Problem is "what it points to" need the MMU.
<moon-child>
flat is justice
<catern>
moon-child: lol
<zid>
Idd
<zid>
I like my justice like I like my displays, trinitron.
mahmutov has quit [Ping timeout: 246 seconds]
<mrvn>
I like my justice unioniced, In a League, you know.,
arch_angel is now known as arch-angel
_xor has quit [Quit: brb]
dequbed has quit [Quit: bye!]
dequbed has joined #osdev
_xor has joined #osdev
wootehfoot has quit [Ping timeout: 272 seconds]
<Griwes>
I really don't want to write too much userspace code with the lowest common denominator of effectively C for interacting with the kernel, but man, exception handling seems like it's the kind of a "do it all at once" deals you can't easily split into smaller chunks
<Griwes>
And it's a prerequisite for the kind of an API I wang to be using
<Griwes>
Guess I will soon become one of the ones cursed with hands on knowledge on this topic
<zid>
The first step to recovery is admitting you have a problem.
<geist>
it's okay, you're among friends here
<zid>
I trust you will eventually make a full recovery and go on to write everything in C
<mrvn>
You want to pass exceptions from the kernel to user space?
<Griwes>
No, lol
<zid>
There's step 2, denial
<Griwes>
But I need to write libunwind and all its friends to have userspace exceptions I can throw from syscall wrappers
<mrvn>
True. So you don't want to write "ssize_t read(...)" now just to later make it "size_t read(...) // throws bla, blu, or blubber"?
<Griwes>
The best source of info on the c++ specific exception tables is in an excerpt from some sort of an HP pdf that was of course originally written for itanium and is of... not very high technical quality lol
<mrvn>
yeah, all the world uses IA64 exceptions
<Griwes>
mrvn: I want to write "mailbox.read().get_token()" while still being able to recover from errors :p
<mrvn>
doesn't your compiler come with a libunwind?
<mrvn>
monads, griwes, monads.
<Griwes>
The only bit of the compiler I'm going to use is the builtins library from compiler-rt
<mrvn>
mailbox |> read |> get_token
<Griwes>
*maybe* the sanitizer runtimes but we'll see
<Griwes>
I'm nowhere near enabling sanitizers yet so I'll worry about that when I get there
<mrvn>
I think unwinding the stack belongs to compiler. It's winding it up it can wind it down too.
<Griwes>
It's a part of the runtime library
<Griwes>
Specifically, libunwind is language and compiler agnostic
<Griwes>
You could argue that the personality function belongs to the compiler, but you can also argue otherwise
<mrvn>
It's simple to argue: If the compiler changes can it break?
<Griwes>
libunwind, no. Personality, potentially, but anything that breaks that is going to have compatibility flags I can enable
<Griwes>
You'd need to change the language specific data format for the personality routine to break, and that's pretty much an ABI break by itself
<mrvn>
See, so personality shouldn't be something you write.
<Griwes>
Disagree
<Griwes>
I want to control the primary ABI for the system
<mrvn>
you can try. Not every language / compiler will follow.
<Griwes>
There's a nonzero chance I'll patch some compiler bits related to this
<mrvn>
You can always provide a personality and ask compilers to use that.
<Griwes>
I don't particularly care about having things that aren't my patched clang working for my OS anyway
<Griwes>
For instance, you need a patch in Clang's middle end to eliminate all PLT entries, which I don't want to see
<mrvn>
If you write the personality and patch clang to use it than the compiler is providing the personality imho,.
<mrvn>
so all good
<Griwes>
It still lives in the runtime library tho :P
jafarlihi has joined #osdev
<jafarlihi>
Have you written bunch of smaller system programs before venturing into osdev?
<mrvn>
I have to pick a movie for bedtime: Rampage or Warcraft?
<mrvn>
.oO(And when will there be a 'The rise and fall of LK' movie?)
jafarlihi has quit [Quit: WeeChat 3.5]
JanC has quit [Remote host closed the connection]
JanC has joined #osdev
<heat>
geist, thanks
<heat>
eau, eventually you'll need to route IO APIC interrupts
<heat>
just know that although the proper solution involves ACPI, you can get the routing if you have a chipset specific driver
<heat>
qemu's default chipset (PIIX4) is pretty simple, just 4 registers in the PCI ISA bus configuration space that tell it how the pins route
<heat>
i haven't looked at the ICH9 (Q35) properly but it's a lot more complex
<zid>
CONFORM
<zid>
Default Q35 is the only valid routing.
<geist>
yah it's why going directly to MSI is almost preferable, though of course not really simpler
<geist>
so can't just recommend it out the gate
<heat>
and VMs are iffy when it comes to MSI support
<zid>
I don't actually understand what the ioapic routing table stuff is actually responsible for tbh
<zid>
I've parsed it out of the seabios but that's when I got distracted by a cool squirrel
<heat>
it lets you rebalance the IRQs
<zid>
ah, makes sense
<zid>
I am still monocore because that's the way god intended it
<heat>
PIIX4 has really low granularity when it comes to that (4 PIRQA-D registers that apply to the whole chipset)
<heat>
modern intel chipsets like the ICH9 have routings for each bus/device
<geist>
ah i see. so it's basically the chipset specific mechanism to modify how irqs are routed. makes sense. all the pci spec stuff ir ead on the topic seemed to imply it was out of the scope of the spec
<geist>
ie, IRQS are supposed to just be A-D and then coalesced up in bridges, but that clearly sucks because then you end up with exactly 4 IRQs for the whole bus complex, so pretty quickly chipsets have mechanisms to unpack it
<geist>
i think the PCI spec says somewhere that this is permissible, but vendor specific
<zid>
Yea that whole PIN#A stuff inherited from pci is weird
<geist>
i always assumed that there was some chipset specific nonsense for it, but never really looked itno it
<zid>
I'm unsure if my 'devices' if I ran the code on a real machine (qemu cheats) would use the legacy pins, etc
<geist>
well easy enough to figure out. just create a qemu config that tosses down a crapton of devices and see how qemu lays it out
<zid>
My guess is that if I booted this code on my real machine it'd just not deliver IRQs until I set up MSI or something
<geist>
i *think* it doesn't try too hard and things get piled up on the 4 IRQs
<zid>
depending on whether the uedeifiefi/bios left the legacy modes enabled etc
<zid>
I've only got legacy options for usb :P
<geist>
well remember on real machines it starts up in the virtual PIC mode where things really are just sort of piled up. i think what's happening with the redirectino tables and whatnot is when you peel that layer away you have the ioapics and all the 'global irqs' and then there's some chipset specific mechanism to route that
<geist>
i dont know how much qemu bothers to emulate the fully unpacked ioapic stuff
<heat>
geist, qemu doesn't balance IRQs, that's the fw's job
<heat>
chipset datasheets very clearly state the defaults
<geist>
right but does it bother to try to unpack them onto global irq pins on ioapics or not
<heat>
qemu sets up hte defaults
<geist>
as you tend to get on real hardware
<zid>
This is honestly the messiest part of x86, who is responsible for interrupt *management* and when, because it changes
<geist>
yep. absolutely
<zid>
I'm not sure it's written down anywhere either
<geist>
it tends to be fairly messy everywhere else too, but usually at the minimum other places usually have a lot more irqs to play with
<zid>
You just kind of have to stop getting IRQs at some point and make sure you've enabled a switchover to something 'more moden' by that point
<geist>
and just having a much larger greenfield of vectors to assign things to helps immensely in general
xenos1984 has quit [Read error: Connection reset by peer]
<geist>
(ie, ARM GIC, RISCV PLIC, MSI allocations, etc)
<heat>
ohh I see
<heat>
I think the ICH9 only routes IRQ pins for chipset-internal devices
<geist>
OTOH e1000 is also a perfectly valid driver to implement. it's a little simpler anyway
<zid>
I already have e1000, but no MSI
<zid>
and I didn't actually see how to set them up cus I was using the old i217 doc or whatever
<geist>
yeah, you can use it with legacy stuff anyway
<geist>
ah i think in the older e1000s (which would be covered by the plain qemu device), MSIs are just implicit i believe
<zid>
my real machine has e1000e though
<geist>
ie, it's routed the same way a legacy IRQ would
<heat>
hm?
<zid>
so it's just fixed to post an msi to irq 16 cpu 0(if A), or whatever?
<geist>
only difference is this capability you fill in and then bobs yer uncle
<geist>
basically. the msi capability is like this 2 or 3 word structure that you fill in the address + data + enable bit and then irqs are routed that way instead of the ABCD pin
<zid>
oh okay, so it's not implicit at all
<geist>
so a device that supports MSI might only casually mention it
<geist>
in their docs, because it's really part of the pci capability space
<geist>
or they'll mebntion it there in passing when they describe what capabilities they'll support, etc
<zid>
the i217 is the pci version I think
<zid>
did pci have msi?
<heat>
no
<geist>
i217 sounds very recent
<heat>
well, im not sure
<geist>
pci did have msi absolutely, pci-e basically mandates it
<heat>
right
<heat>
my bad
<geist>
but only very late model pci stuff uses it, since MSI came along more or less right as pci-e was coming along
<zid>
i217 became 82577** at some point
<zid>
with letter codes
<geist>
it effectively looks like a bus mastering DMA from pci's point of view, so there wans't any hardware needed for legacy PCI to support it
<zid>
and then e1000e is some other 825 number afaik
<geist>
no. it's far more complicated than that, unforunately
<geist>
anyway, lets see. what level of MSI does this support...
<heat>
the ICH9 has serial IRQs
<zid>
I had a bunch of pdfs, but god knows where they are
<heat>
cray-cray
<zid>
I had like, two different pdfs I liked for describing different parts of it too
<geist>
sure. in my limited amoutn of fiddling i looked at what qemu emulates and what they tend to call e1000 and e1000e, which i think basically follows what linux does
<geist>
it's a fairly arbitrary line in the sand, since you *could* write a single driver for the whole line
<bslsk05>
github.com: lk/lapic.c at master · littlekernel/lk · GitHub
<geist>
needed to EOI the msis
<geist>
i found that after implementing the MSI support
<zid>
yea I was reading the regs, there's masks and eois and stuff
<geist>
zid: re: lapic base i think it's pretty safely *always* at the same spot
<zid>
and a master enable
<heat>
oh yeah
<zid>
Yea probably, and there's always the msr to just ask it where it got moved it anyway
<geist>
and in that code i just read the base out of a MSR
<zid>
exactly
<heat>
you can read the lapic base out of the msr
<geist>
which i think is also perfectly legit
<geist>
ioapic is what you need acpi and whatnot for
<zid>
okay so that's a job I can do next time I look at this stuff
<zid>
switch the e1000 over to MSI, turn off the pic at last
sonny has joined #osdev
<heat>
add SMP
<geist>
yep. what you'll have to add to your pci code is some way to walk the capability table and look for a MSI capability
<geist>
but it's pretty easy
<zid>
It's still a shame I have to do io ports for that one specific thing, turning the pic off :P
<zid>
I already have that geist
sonny has left #osdev [#osdev]
<geist>
also you'll want some sort of allocator for IRQs, since you'll need to dynamically allocate them for each MSI
<zid>
because of erm.. virtio-net? I forget
<geist>
i just tossed some shitty bitmap together with 256 bits and called it done
<heat>
zid, virtio devices yeah
<zid>
You have to walk the caps to figure out the device that each subdevice is and they're bundled or something? I forget
xenos1984 has joined #osdev
<heat>
you need to get stuff where you're going to put stuff iirc
<geist>
yah i still need to do that. my virtio code currently only handles mmio, since thats what you can call up on the arm and riscv virtio interface
<geist>
need to abstract it such that can work over pci as well
<zid>
I'm not even sure that code is used, I never finished virtio
<bslsk05>
github.com: Onyx/virtio.cpp at master · heatd/Onyx · GitHub
<zid>
It's still a shame I have to do io ports for that one specific thing, turning the pic off, I basically only moved to pci-e at all because pci config space being on that bus was gross :P
<geist>
yah that being said i haven't found the pci io config accessors to be too bad
<geist>
just wrap it behind a function and then dont think about it ever again
<zid>
yea I have a switch() for it (function pointers for two whole entries felt a bit meh)
<heat>
weird chipsets have weirder ways to access it
<zid>
switch(d->bus) case BUS_PCI: return pci_read_u32(d->pci, offset); case BUS_PCIE: return pci-e_read_u32(d->pcie, offset);
<zid>
and the pci one does some in and shift, the pci-e one does a memory read
<zid>
and there's a union for pci-e base vs ioport base
terminalpusher has quit [Remote host closed the connection]
<bslsk05>
github.com: boros/types-pci.h at master · zid/boros · GitHub
<geist>
i think the key to the whole thing is to make sure you dont bake into your design that you can implicitly access the config in a memory mapped way
<geist>
since that's generally implied with modern ECAM, but not necessarily
<zid>
delete pci, aquire pci-e and no union tag :P
<zid>
save 4 bytes per device
<geist>
key is lots of times various virtual machines or whatnot dont bother implementing the ECAM, because they dont have to
<geist>
ie, if you're emulating a machine that just has a few devices on it and there's no physical pci-e link, then most of the extended pci-e config stuff is not necessary
<heat>
you can also have lots of ECAMs
<zid>
That's fine, I don't need an Electronic centralised aircraft monitor
<geist>
and emulating a io based pci accessor is actually a lot easier
<geist>
since the vmexits are more obvious what they want
<geist>
i remember early on in fuchsia we had the same thought: lets only bother with pci-e and forget the legacy stuff
<geist>
alas, no. lots of VMs dont do ECAM
<heat>
all I want is a VM that emulates power management
<zid>
OH enhanced configuration mechanism
<heat>
suspend, resume, Dx states for devices and buses
<zid>
I thought ecam meant the 4k mmio region pci-e added
<heat>
no, ecam is the access mechanism
<geist>
yah though it's implied with it, since the ECAM is the large physical run of 4K config blocks laid out in a particular addressing mode
<zid>
i assume that just gets decoded by the controller
<geist>
yah
<zid>
and each device has its own 4k of actual memory on its client chip
<heat>
yes
muffin has left #osdev [WeeChat 3.5]
<zid>
how do you.. not use ecam though
<geist>
or registers generally. i dont think there's an assumption that you can write to most of it
<geist>
the legacy pci io accessors
<zid>
registers are just memory with bad PR
<geist>
however, those can't access > 256 bytes in the config space
<zid>
yea like.. I'm confused
<geist>
whcih is why pci-e extended config descriptors all live >256 bytes into config space
<zid>
I swear you were saying "You had better make sure you support the legacy stuff, like ECAM"
<zid>
and I'm like, how the fuck do you avoid ecam
<geist>
you use the thing before ECAM existed
<geist>
ECAM came along with pci-e
<zid>
geographical ISA bus banana method, everybody's favourite
<bslsk05>
github.com: boros/pci.c at master · zid/boros · GitHub
<zid>
snap?
<geist>
hmm, okay. i've generally seen it called 'type 1 accessor' because there's some other type that nothing uses anymore called type 0
<geist>
snap?
<zid>
I supported PCI then PCI-E
<zid>
you linked it, I linked it
<geist>
uh. okay.
<zid>
you know, the children's card game?
<geist>
i'm trying to be informational, not be some sort of one upmanship
<zid>
wat
<zid>
I'm even more lost now
<geist>
but anyway
<geist>
what i dont know is how the legacy pci accessor stuff ever worked on other architectures
<geist>
like alphas with PCI or sparcs with PCI
<zid>
it sounded like you were trying to explain what you meant by geographical, and linked an your impl that made it clear what it was, so I linked mine back and said snap, not sure how that's you taking it as me taking it that I think you're one- that sentence is hard I give up
<geist>
all the modern non x86 stuff seems to just supprt ecam
<zid>
I saw the geographical stuff somewhere on an arm device somewhere but I really do forget, and it probably had ecam anyway
<zid>
if the non-ecam even worked in reality idk
<zid>
it just had a bar or devicetree entry for the ioport region for pci config, I can't even remember that much
<geist>
yah. the only other one i know about is a method that i've seen some synopsys pci stuff use
<geist>
whcih is truly gross. it's a combination of ecam and io port style stuff
<geist>
ie, you write something somewhere and it causes a window of the 'ecam' to become visible
<zid>
oh it may have been when I was looking up a certain pci-e to pci bridge
<geist>
so you can only look at one device at a time
<geist>
it's kinda the worst of all worlds, because it makes all the accseses non atomic. though i guess the io port stuff is the same
<zid>
and the pci-e bridge had a BAR for how to access the pci device it decodes for's geo/iorport region? memory failing
<geist>
the io port stuff you can just toss a spinlock around, there was something about this mmio swap thing that made that hard for a reason i forget
<zid>
lspci -vvv is fun to run on random machines you have ssh access to
<zid>
now that I can read the stuffs
kpel has joined #osdev
<zid>
I get to add device_eoi or something I guess once I add msi, generify that too
<zid>
so that I can ack pic or msi or whatever else
<zid>
And then write some big infrastructure to patch it at runtime for perf, right?
<heat>
obv
<zid>
Need a code union
<zid>
union { asm("out PIC, ack"); lapic_base[lapic_eoi] = 4; }
<sortie>
I think I managed to fix both the crashes and memory leaks in my TCP stack
<zid>
both of the *known* crashes and leaks
<zid>
it's tcp, give it 30 more years for security reasearches to pick it to pieces
<sortie>
Def a couple more leaks
<sortie>
Not as serious though and more fixable now if I just get a bit more TCP machinery right
<sortie>
The TCP socket lifetimes are at least well defined now
<sortie>
Hard to know if I made a mistake without subjecting a server to a whole bunch of internet background radiation
<sortie>
Fortunately I do have such a server :D
<zid>
all the cool attacks require subnet access though
<zid>
arp poisons and sequence cheating and stuff
<sortie>
Nah just send me a stray SYN
<zid>
I'll just send you one of every flag combination
<sortie>
At least that doesn't leak anymore
<zid>
in every possible order
<zid>
should only take those 30 years
<sortie>
Still a whole bunch of denial of service attacks possible
<sortie>
4032 B 18 allocations net/tcp.cpp:697 accept4
<sortie>
4727232 B 18 allocations net/tcp.cpp:1229 ProcessPacket
gildasio has quit [Ping timeout: 240 seconds]
<sortie>
^^^ I built some neat debug kernel allocation tracing that lets me know how many bytes/objects from a given allocation point are currently alive. This lets me know that 18 TCP socket file descriptors are currently alive and 18 incoming TCP connections are alive. The two counters can differ while connections are in the queue, or being closed, or well, when they leak.
<geist>
noice
gildasio has joined #osdev
<sortie>
It's totally testing in production, but handy I can deploy my fixes and just ssh into my OS and see if it's still up and not leaking