nick64 has quit [Quit: Connection closed for inactivity]
teroshan has joined #osdev
<geist>
for some reason this all has me interested in putting in the basics for AMD based virtualization
<geist>
VMX too, but the AMD one is what i have on most of my machines nowadays
<geist>
and it looks simpler
dude12312414 has joined #osdev
troseman has quit [Read error: Connection reset by peer]
troseman has joined #osdev
Celelibi has quit [Remote host closed the connection]
phr3ak has quit [Excess Flood]
gog has quit [Quit: byee]
hbag has quit [Ping timeout: 256 seconds]
Celelibi has joined #osdev
phr3ak has joined #osdev
epony has joined #osdev
V has quit [Remote host closed the connection]
<friedy10->
Does anyone know how I can disable the serial port in linux while keeping the memory mapped in for the device?
<zid>
delete the device from proc? :P
<zid>
depends what you mean by 'disable'
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
<zid>
if you just want nobody to be able to use it, rebuild the module without the code that does the reading or writing or something, if you just want programs not to, change ownership of the /dev file to root, blah blah
nyah has quit [Ping timeout: 256 seconds]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
sdfgsdfg has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.4]
V has joined #osdev
<geist>
friedy10-: also what kind of serial port are you talking about?
<geist>
i assume you mean you want linux to not try to drive it with one of its drivers so some user space program can directly control it?
[_] has joined #osdev
[itchyjunk] has quit [Ping timeout: 240 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<friedy10->
I'm running linux as a guest with another kernel on a hypervisor. I'm trying to access a serial device (uart) with my kernel, but my kernel gives me page faults because I can't access the device while linux is using it.
<friedy10->
I just disabled the serial device in the kernel config, and it sort of works now on my kernel.
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
<friedy10->
This is pretty annoying. I'll explain the problem more tommorrow, but I think I'm pretty close.
ElectronApps has quit [Remote host closed the connection]
<klange>
yay i have a functioning timer irq again, and it looks like my perf tracking is working too
terrorjack has joined #osdev
Lugar has quit [Ping timeout: 240 seconds]
ElectronApps has joined #osdev
<geist>
oh yay. which of the 4 timers did you end up using on ARM?
<klange>
currently running this signal off the virtual system timer
<geist>
that's the one, yup
<geist>
took me some time to fully grok the 4 timers, and i got it wrong at some point, but AFAICT the virtual timer is the one you should go for, even on real hardware
smeso has quit [Quit: smeso]
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
smeso has joined #osdev
<Clockface>
for an emulator, i came up with putting a bunch of jumps at a given offset from location X
<zid>
yea that's called a jump table
<zid>
that's basically what a switch() would compile to, which is normally what you'd do anyway for a basic emulator
<Clockface>
then for each opcode, its value is added to location X so that the program goes to that jump
<Clockface>
oh, thats nice
<Clockface>
i dont plan on using C too much though, since im trying to pick registers on the real CPU i can "map" to the virtual one
<geist>
of course it depends on what you're emulating
<geist>
on how the branching works, or if it can be directyl mapped
<geist>
but say 8 bit cpus are great for simple jump tables like that
<Clockface>
its a real mode emulator for long mode
<geist>
wow.
<Clockface>
?
<Mutabah>
Enjoy :)
<Mutabah>
(I wrote one once, testing was ... fun)
<Clockface>
ah, have i gotten myself into something horrible?
<geist>
oh heh, i read it the other way
<geist>
(long mode emulator for real mode)
<geist>
but either way it's fun :)
<Clockface>
oh god no
<Clockface>
lol
<zid>
using host regs to store client regs is a neat optimization
<Mutabah>
That'd just be porting bochs to 16-bit :D
<zid>
I did consider doing it once for gbz80 but never got around to it
<Clockface>
its supposed to be a substitute for protected modes virtual 8086 mode
<Mutabah>
Do it for fun if you want, but BIOS calls are pretty much useless nowadays
<Mutabah>
(With the proliferation of uEFI)
<Clockface>
i just want my 64 bit IBM PC compatible, ok?
<Clockface>
the first thing i have in mind to use it in is a DOS extender
<klys>
djgpp is a pretty good dos extender, scares devs away though with the licensing, it just needs to be able to map more than one program to the same address space, I tried doing so and it breaks the memory allocator for bash
<klys>
go32-v2 is under a djgpp specific copyleft
<Clockface>
im the emulator itself under my normal linux system, i dont see any reason i couldent port it around to whatever i need it for
<Clockface>
*developing
<klys>
well there are some constraints with pmode, depending on if or how you use paging and allocate memory. the allocator is the difficult part, then you get to write the scheduler (after the allocator is perfect).
<Clockface>
the emulator manipulates the same adresses specified by the code its running
<Clockface>
i would put the emulator itself above the 1 MB barrier so whateve rits running doesnt shoot everything in the foot
<Clockface>
*whatever
<klys>
well then you have to do some pretty involved stack switching and parameter passing
<klys>
really though the osdev wiki says the way forward is to follow the page tables and implement sbrk() with page fault handlers
<Clockface>
one idea i do have, though it sounds like it has something deeply wrong with it
<Clockface>
is to write the emulator itself to not use the stack, so i can use the stack just for the emulated program
<Clockface>
it might simplify things?
<zid>
the stack needs to be in the application's memory anyway
<zid>
how else do you expect to do mov ax, [sp] etc?
<klys>
well that sounds tricky, and may end up being more tricky than it's worth. you could try using a register as an alternate stack pointer, though you'd end up getting some convoluted steps in your emulation. perhaps start out with some macros like, mov [es:edi],param; sub edi,4; etc.
<zid>
I'd wager it's not even possible.
<klys>
beware though that your changes to es aren't going to lock the bus for the next instruction like changes to ss do
<zid>
You'd need to carefully guess whether the program being emulated was trying to access the stack or not on every op, then intervene to redirect it to your fake stack
<zid>
rather than just.. emulating them as normal
<Clockface>
i guess
<Clockface>
ill think about it a bit
<zid>
I'm not sure what your trepidation is?
<zid>
You've already got a super easy job because you don't need to care about devices or interrupts
<Clockface>
well i just need to think about what to do about my stack
<klys>
with your regular push instruction, you can push [eax*4+20]; to emulate that you'd need to sacrifice at least one register.
<klys>
iirc
<zid>
why is the stack special to you?
<zid>
It isn't to me
<Clockface>
it has to work doesnt it?
<zid>
what's stopping it working if you just do exactly what the ops say to do
<zid>
it's just a question of doing switch(op) case 0x47: cpu.AX = cpu.BX; break; case 0x48: cpu.AX = cpu.CX; break;
<zid>
stack will work correctly as long as you implement the op correctly
<Clockface>
well yeah, there are several ways to implement the op
[_] is now known as [itchyjunk]
<zid>
not really?
<zid>
the intel manual even gives psuedocode for what each op does
<zid>
SP ← SP – 2;
<zid>
Memory[SS:SP] ← SRC;
<zid>
(* push word *)
<Clockface>
yeah, but thats just the behavior of it
<Clockface>
there are still a few options to make that behavior happen
<zid>
If you don't do 'emulated SP = emulated SP - 2; then 'write SRC to the emulated memory at address ss:sp' then your emulator is just.. wrong
<Clockface>
well, you could write an 8086 emulator in python, which i would assume would function very differently from one written in assembly to be OS-indipendent
<zid>
not in the least
<Clockface>
but they would still run the same programs because from the emulated programs perspective, you end up with the same behavior
<zid>
you'd still end up comparing the opcode byte to see which operation it is, subtracting 2 from a variable holding the emulated Sp register, and do a write to emulated memory at ss:sp
<zid>
anything else is just wrong, the cpu won't do what it's supposed to do
<zid>
(assuming both are interpreters, dynarec is also an option but you still end up doing this, just elsewhere than at runtime)
<Clockface>
yes, it has to behave the exact same from the perspective of the emulated program
<Clockface>
but beyond that, it doesnt care
<zid>
More or less, yes, but given how simple each operation actually is
<zid>
there isn't actually any room to really do anything other than the two direct steps it encodes for
<Clockface>
im not saying there are a lot, im just saying i have more than one
<zid>
such as?
<zid>
That was my original question
<Clockface>
how to make something that behaves as the stack should
<zid>
okay so what's the alternative to mem[ss:sp] = src;
<Clockface>
like i said, im honestly curious if the emulator itself needs the stack
<kazinsal>
remember to triple fault if SP == 1
<Clockface>
ah, true
<zid>
That's actually above that line in the psuedo :P
<Clockface>
in that case if im going to implement behavior like that i might not want to use the emulator as a wrapper for the real stack
<Clockface>
but thats what i meant, you could either emulate a stack, but i considered using the real stack to store the emulated programs stack as an option
<zid>
it really isn't
<kazinsal>
just emulate it all
<zid>
It like, really really really isn't, because now every single memory access needs to somehow check if that address had ever been 'push'd to
<zid>
and if that data is still alive
<zid>
so that you can intercept the read/write and redirect it to your host stack
<kazinsal>
the cost of a few extra memory accesses here and there isn't higher than the cost of complexity of trying to hack around with overlapping stacks and awful stuff like t hat
<klys>
00000000: 67ff348514000000 push word [dword eax*4+0x14]
<kazinsal>
I think that right there is one of the tricky parts of from scratch x86 emulation. all the ridiculous addressing modes
<zid>
case push: asm("push ax"); case pop: asm("pop ax"); case movaxss: cpu.ax = mem[cpu.SS];
<Clockface>
yes
<Clockface>
yes it is
<Clockface>
its what i have to spend the most time thinking about
<Clockface>
im also overthing the stack, but thats arguable unnecissary
<zid>
decoding is the hard part of x86, thankfully real mode is relatively simple
<Clockface>
real mode is nice
rustyy has quit [Quit: leaving]
<zid>
Given you don't have interrupts or devices etc, you don't even have to care about cycle counting, which makes the code in each op completely braindead also
rustyy has joined #osdev
<Clockface>
yeah exactly
<zid>
If you can write a decoder that doesn't twist itself into knots, you're basically already finished
<Clockface>
thats why im doing it, because im relatively braindead too for now
<Clockface>
and afterwords i will be less braindead and have a handy emulator
<zid>
allocate a meg of ram, a struct with ax, bx, cx, dx ... + cs/ds/es/ss in it, smash out some instructions, and decoder hopefully sets up the overrides properly for which selector gets used etc
<zid>
dones
<Clockface>
since the emu runs on x86-64, im hoping to store some of the 8086 registers in the extra ones
<zid>
Ideal world being you don't duplicate the code for mov ax, [si] and mov ax, [es:si], decoder sees the override byte and just does base = ds; or base = es; and the actual op does base + si, for example
<Clockface>
brb
<zid>
You won't actually see a speed increase on that on an actual x86_64 cpu fwiw
<Clockface>
really?
<zid>
interps are slow because of all the failed branch prediction
<zid>
and 'slow' here is relative, you'll be running.. a few thousand instructions, over the course of a handful of microseconds
<Clockface>
oh
<Clockface>
alright
<zid>
the cpu->ax memory deref disappears into the branch prediction miss, it'll prefetch it all
<Clockface>
brb
<zid>
If you care about speed you'd write a dynarec instead
<Clockface>
before i go, why would storing a bunch of values in the additional registers be slower than memory access?
<zid>
it isn't slower, it just isn't faster
<Clockface>
i see
<Clockface>
thank you
[itchyjunk] has quit [Read error: Connection reset by peer]
<Clockface>
back
<kazinsal>
registers are maybe twice as fast as L1 cache but they're not persistent whereas the processor should likely end up keeping your struct cpu { ... } in L1 or L2 (which then ends up in L1 pretty quick)
<clever>
i think that in general, registers are the fastest, and any opcode dealing with only registers will run in a deterministic amount of clock cycles (baring modern optimizations, that mean you have to count nearby opcodes too)
<clever>
and each cache tier is then slower then the previous, and yeah, L1 being slower then registers
<kazinsal>
I think Intel usually estimates registers to be 1 TB/s, L1 and L2 to be 500 GB/s (1 ns and 4 ns latency respectively), L3 to be 150-250 GB/s
<clever>
but writes can often cheat, and just push the data into a FIFO that runs at full cpu speed
<clever>
so if you are only writing to the L1 cache, the cpu doesnt have to slow down as much
<clever>
until it fills that fifo?
<kazinsal>
yeah the CPU should be able to parallelize sequential writes to L1 cache lines
<zid>
and basically what will happen is that the cpu gets told to write to the regs/L1, then you will branch on decoding the next op which don't have depenencies on those values
<zid>
and they will all retire while you do the decoding, 'for free'
<zid>
so your bottleneck is almost entirely the branch prediction for the decoding
<clever>
i think the biggest bottleneck is reads
<clever>
because you cant just cheat and throw it into a fifo and deal with it later in paralel
<clever>
prefetch can help, but can only go so far
<clever>
!ping
<clever>
!ping
<kazinsal>
pong
<klys>
pong
<clever>
i said those ping's 2 mins apart, but the logs page shows them back to back
the_lanetly_052 has joined #osdev
the_lanetly_052 has quit [Max SendQ exceeded]
the_lanetly_052 has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
<Clockface>
is there any way to get how long an opcode is exactly in NASM?
<zid>
an instruction? assemble it then check the size of the file, or put a label either side and subtract, loads of ways
<Clockface>
ty, i like the second one
sdfgsdfg has joined #osdev
troseman has quit [Read error: Connection reset by peer]
the_lanetly_052 has quit [Ping timeout: 256 seconds]
GeDaMo has joined #osdev
<klange>
really can't find a viable solution to recording the screen on this thing as obs just doesn't work, gnome's built-in screen recorder is useless...
<bslsk05>
'ToaruOS on AArch64 (KVM on a Raspberry Pi 400)' by K Lange (00:01:44)
gog has joined #osdev
<sortie>
klange, wow you're making some really neat progress!
<sortie>
The host machine is an RPi4 even?
<klange>
aye, getting to deal with all the cache fun
<kazinsal>
:toot:
<klange>
still a lot on the TODO list but great to have keyboard+mouse and be able to actually use the OS interactively
<sortie>
It's starting to look pretty fully featured (survivor bias), what's the biggest tasks still left?
<klange>
So a lot of this is hacked together and has harcoded assumptions based on the QEMU virt machine; bunch of stuff needs to be fixed up with the device tree binary parsing.
<sortie>
What's the differences between qemu and a physical rpi4? How long before you can boot it native?
<klange>
I need to go flip through an RPi4 barebones guide, but Raspberry Pis have a very special boot process...
<bradd>
how do I display text after exit_boot_services()? The standard write to 0xb8000 doesn't seem to be working for me.
<klange>
bradd: If you are using EFI you do not have VGA text mode, it does not exist.
<bradd>
ok. guess then use gop and load a font then?
<j`ey>
sortie: graphics is a lot different!
<gog>
bradd: it's not that simple
<klange>
j`ey: Thankfully purposes, not too different... some mailbox stuff back and forth and you've got a framebuffer? I've done it before on an older rpi.
<gog>
you'll need a text renderer
<klange>
for my purposes*
<gog>
unfortunately
<bradd>
yes, I get the idea. start video using gop, get the framebuffer, make my font rendering stuff
<gog>
bradd: the other option is to just use the serial port that UEFI sets up to get text output for now
<klange>
I think the harder thing on the RPi will be input devices. It's basically USB or bust.
bauen1 has quit [Ping timeout: 268 seconds]
<gog>
it'll stlll work fine in PIO after exitbootservices()
<klange>
I slapped together virtio-input stuff for this VM.
<bradd>
I do that. serial port is my main debugging output
<kazinsal>
embrace weirdness, use misc-fixed-6x13 as your terminal font
<gog>
ah good
<klange>
write a truetype parser and use deja vu sans mono
* klange
sips beverage
<gog>
write a full truetype engine in your kernel
<bradd>
lol, starting with simple fixed width fonts
* gog
stares at microsoft
<kazinsal>
gog: dave cutler is angry at you for this
<klange>
I think I do too much floating point in mine to put it in my kernel...
<gog>
kazinsal: he should be
<zid>
I pirated unifont and it's built into the kernel binary muhahaha
<kazinsal>
(he was notably opposed to the GDI people shoving their font rendering code into the kernel for performance)
<gog>
klange: your fonts do look damn nice
<j`ey>
klange: can you just do all the parsing right at boot time, and store the results, to not need some floating point? :P
<gog>
not if you're doing proper kerning
<j`ey>
aw
<gog>
you'd need to store basically every possible digraph and merge at run time
<kazinsal>
signed distance field text reendering gets *close*
<kazinsal>
but it's still imperfect
<klange>
So I think you can manage to do it all fixed-point, but _good luck_.
<klange>
my SDF rasterizer was all floating point, too...
<bslsk05>
github.com: boros/print.c at master · zid/boros · GitHub
<g1n>
ok
<zid>
or you can just write it twice, whatever :D
<klange>
my printf has a long and storied history; the decimal and hex formatters are still pretty old, but the core got a majro rewrite a year ago when I was porting my interpreter to EFI
<klange>
and that then got pulled back into my kernel and libc
catern has joined #osdev
<klange>
for a while my kernel and libc ones were split, as the kernel one was... non-standard, we'll say
<zid>
I like a good non-standard printf
<zid>
with format specifiers for all your internal object types
<g1n>
ok, seems done it (currently a bit ugly but i will fix it)
<klange>
zid: that would be the smart kind of non-standard, whereas I am using it as a euphemism for broken
<zid>
hah
<g1n>
zid: should i use -m for qemu?
Irvise_ has quit [Quit: Client limit exceeded: 20000]
<g1n>
because, idk why, after some time, it just resets
<g1n>
so i wait like 10-20s and it resets
Irvise_ has joined #osdev
<g1n>
hmmm, it works with %d lol
<zid>
no idea what -m is
<zid>
ah, ammount of memory
<g1n>
yep
<g1n>
i don't want to break my computer if i do smth wrong there wrong
<g1n>
s/wrong//
<zid>
wha?
<g1n>
once i did smth wrong with pointers in idt and it freezed my computer a lot
<g1n>
idk why
<g1n>
now everything is fine
<gog>
because it was probably #GP
<gog>
but you don't have a #GP handler
<gog>
so it #DF
<gog>
but you don't have #DF handler
<gog>
so it triples
nopenope[m] has quit [Quit: Client limit exceeded: 20000]
<g1n>
gog: when i try to print memory?
<gog>
maybe
nopenope[m] has joined #osdev
<zid>
interrupt storm in the client could maybe lag the host due to all the vmexiting or whatever maybe?
<zid>
but if your host crashes then it's a bug in qemu
<zid>
and your host's kernel
<gog>
oh hm
junon has quit [Quit: Client limit exceeded: 20000]
<g1n>
i don't have that problem currently, i am trying to detect memory for now
junon has joined #osdev
<g1n>
hmmmm, it still resets when i am trying to use %x
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
<zid>
try not writing to silly memory then
<zid>
You may wish to tell qemu not to reboot and to enable interrupt tracing
<zid>
-d interrupt -no-reboot -no-shutdown or whatever it is
paulusASol has quit [Quit: Client limit exceeded: 20000]
<g1n>
ok thanks
paulusASol has joined #osdev
<gog>
-d int
<g1n>
yep, it worked
<g1n>
zid: check_exception old: 0x8 new 0xd
<g1n>
seems after that it reseted last time (on this thing it pauses)
<zid>
Yea that's a DF, go one higher you'll probably see the original fault
<g1n>
zid: check_exception old: 0x0 new 0xd
<zid>
divide error, neat
<g1n>
check_exception old: 0xffffffff new 0x0
<zid>
never actually caused a divide error myself
dude12312414 has joined #osdev
<zid>
sounds like you tried to divide by 0, it should tell you what eip/rip was
<zid>
afaik the memory map is in ebx to begin with?
<g1n>
i just use grub
<g1n>
nothing else
<zid>
>afaik the memory map is in ebx to begin with?
<zid>
ebx + some offset, anyway
<g1n>
hmmmm
<g1n>
but i mean, i don't understand if i should do that or grub?
<klange>
in multiboot1? ebx points to a multiboot header
<zid>
you should do what
<zid>
I'm saying what's in a register
<zid>
there is no active verb there
<g1n>
oh
<zid>
+40, by my count
<zid>
oh no, syms is bigger
<zid>
56 ish?
<zid>
counting is hard, 52 final answer.
<g1n>
zid: this is what qemu shows me - EBX=00007d44
<zid>
Okay so dump 64 bytes of memory at 7d44 please
<zid>
xp /64bx 0x7d44
<zid>
afaik
<g1n>
wait, how? i didn't understand you :(
<zid>
in qemu
<zid>
type xp /64bx 0x7d44
<g1n>
oh
<g1n>
ok
<g1n>
it shows just a lot of zeros
<zid>
Then you failed to check ebx at boot
<zid>
and already corrupted it somewhere
<g1n>
but a value that was 2 qemu outputs before shows smth
<zid>
your breakpoint is too late
<zid>
set it to whatever you put into entry_addr in your multiboot header
<zid>
or whatever you put into the ELF
<zid>
depending on which you're using
<g1n>
i have mbd->mmap_addr
<zid>
you don't have `mbd` according to what you just told me
ElectronApps has joined #osdev
<zid>
You told me it was at 0x7d44 then we dumped it and it was all zeros
<g1n>
i mean in C code
<klange>
but mbd sounds invalid
<g1n>
oh
<zid>
you've not verified anything so far so we're just having to do it all now, all we have is a screenshot showing that you obviously printed the wrong memory, or printed the right memory incorrectly
<g1n>
yes
<g1n>
ok, maybe i will put break after first memory map output?
<zid>
the first step is to check you have a valid multiboot information structure
<zid>
break at the entry point.
<klange>
print early, print often
<zid>
we need to find the FIRST place you go wrong
<zid>
if we're 10 steps deep it's too late
<zid>
we don't know if the problem is garbage in, or garbage out
<g1n>
sorry, i will try it, i need to go
<g1n>
thanks
ElectronApps has quit [Ping timeout: 250 seconds]
bauen1 has quit [Ping timeout: 256 seconds]
bauen1 has joined #osdev
dennis95_ is now known as dennis95
the_lanetly_052_ has joined #osdev
EtherNet has quit [Quit: WeeChat 3.4]
hbag has joined #osdev
the_lanetly_052 has joined #osdev
zhiayang has quit [Quit: oof.]
zhiayang has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 256 seconds]
EtherNet has joined #osdev
fwg has quit [Ping timeout: 250 seconds]
the_lanetly_052 has quit [Ping timeout: 250 seconds]
fwg has joined #osdev
srjek has joined #osdev
ElectronApps has joined #osdev
mahmutov_ has joined #osdev
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
ElectronApps has quit [Remote host closed the connection]
bas1l is now known as basil
JanC has quit [Remote host closed the connection]
JanC has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
elastic_dog has quit [Ping timeout: 252 seconds]
gwizon has joined #osdev
nick64 has joined #osdev
PapaFrog has quit [Read error: Connection reset by peer]
LostFrog has joined #osdev
elastic_dog has joined #osdev
mahmutov_ has quit [Ping timeout: 250 seconds]
bauen1 has quit [Ping timeout: 256 seconds]
bauen1 has joined #osdev
mahmutov_ has joined #osdev
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
bauen1 has quit [Ping timeout: 256 seconds]
bauen1 has joined #osdev
bauen1 has quit [Ping timeout: 260 seconds]
bauen1 has joined #osdev
bauen1 has quit [Ping timeout: 256 seconds]
[itchyjunk] has joined #osdev
bauen1 has joined #osdev
heat has joined #osdev
srjek has quit [Ping timeout: 250 seconds]
<heat>
how good of an idea would it be to increase logical page sizes for existing architectures?
<heat>
such that you always deal in pages of PAGE_SIZE(8KB, 16KB, etc) but the underlying MMU's page size keeps being 4KB
<heat>
there would be an issue with allocating pages for page tables (where half of the logical page would be unused) but that could be worked around
gwizon has quit [Quit: Lost terminal]
<clever>
heat: ive had bugs before, where i wasnt specifying alignment for structures passed to hw, and it only worked because something unknown was forcing a higher alignment, and then i ported it to another kernel, and that magic went away
<clever>
forcing 8k alignment on everything might make such things worse
<clever>
by making them work on some setups
fwg has quit [Ping timeout: 252 seconds]
fwg has joined #osdev
dennis95 has quit [Quit: Leaving]
<heat>
clever, but that's not really the kernel's concern is it? also it could presumably be made configurable so the kernel could support 4K, 8K, 64K
<clever>
yeah
<heat>
you would just need your mmu code to separate the concept of logical page from the MMU page
<heat>
could probably be made boot time dynamic too (although that would be yucky)
heat has quit [Ping timeout: 250 seconds]
vin has joined #osdev
dormito has quit [Ping timeout: 256 seconds]
srjek has joined #osdev
dormito has joined #osdev
brynet has quit [Remote host closed the connection]
fwg has quit [Quit: .oO( zzZzZzz ...]
fwg has joined #osdev
GreaseMonkey has joined #osdev
brynet has joined #osdev
srjek has quit [Ping timeout: 260 seconds]
MrPortmaster is now known as MrBonkers
<geist>
klange: oh woot. so you got virtio-input working. against the mmio or pci aperture?
<geist>
hbag: re: logical vs physical. yeah that'd work. you wouldt get any TLB gains, but you'd be tossing around less pages in general
<geist>
less page faults, etc
<geist>
er, heat
<hbag>
huh what
<geist>
sorry hbag for the mis-tag!
<hbag>
oh lol
* sortie
, o O (don't forget to geist)
<sortie>
geist, actually ran into your username at work when I found a bug for a fuchsia macOS arm64 toolchain :)
<geist>
oh?
<geist>
i dont think there is one yet, but the build system points it at rosetta versions
<geist>
and it works surprisigly well
<sortie>
Yeah we're using rosetta on our mac M1's for that reason too
<sortie>
Would be cleaner with a real toolchain tho, sent me on a whole side quest figuring out how to get rosetta on our bots
<sortie>
It all magically works \o/
blockhead has joined #osdev
<geist>
yah hopefully we'll get some native ones eventually
<geist>
there are *lots* of prebuilts
<geist>
side note there's a discord for fuchsia that you might want to pop into
fwg has quit [Quit: .oO( zzZzZzz ...]
GeDaMo has quit [Remote host closed the connection]
fwg has joined #osdev
sdfgsdfg has joined #osdev
<gog>
ok i'm a little unclear about something. the fields in the x86_64 tss are offset 4 bytes, so if alignment check is on is it gonna throw if i try to write to the qword fields misaligned?
<gog>
should i be doing two dword writes intead?
<gog>
or does that only apply when CPL>0
puck has quit [Remote host closed the connection]
bslsk05 has quit [Remote host closed the connection]
puck has joined #osdev
dormito has quit [Quit: WeeChat 3.3]
bslsk05 has joined #osdev
fwg has quit [Quit: .oO( zzZzZzz ...]
nyah has quit [Remote host closed the connection]
nyah has joined #osdev
mahmutov_ has quit [Ping timeout: 256 seconds]
Vercas has quit [Quit: buh bye]
<Bitweasil>
I'm pretty sure alignment doesn't care what you're writing to.
fwg has joined #osdev
<moon-child>
gog: yeah looks like only ring 3
<gog>
ok that's what it looked like to me
<gog>
thanks
<gog>
Bitweasil: this was just the specific case i'm wondering about
<gog>
not that i thinnk the TSS is special
srjek has joined #osdev
sham1_ has joined #osdev
sham1 has quit [Ping timeout: 240 seconds]
<Bitweasil>
Oh, ok.
fwg has quit [Quit: .oO( zzZzZzz ...]
Vercas has joined #osdev
<klange>
geist: pci, easier to find with what I have
Vercas has quit [Quit: buh bye]
<geist>
cool yeah i haven't actually added virtio pci stuff yet. there ae a bunh of annoying capabilities, but it seems okay once you get it working
<geist>
or just hard code it :)
Vercas has joined #osdev
<klange>
I just hard coded the offsets/bar for now. Great to have input, will help a lot with testing as I work on more things. Should get a virtio-net driver together next...
<geist>
woot yeah
<geist>
i haven't looked at it in a while but i do remember the wraparound cases and whatnot for the virtio ring buffer to be slightly wonky
<geist>
but it may have just been the first time i'd ever written a driver for something like that, and now its super obvious
sham1_ is now known as sham1
gog has quit [Quit: byee]
dormito has joined #osdev
<klange>
I think aarch64 on TCG on my desktop is faster than x86-64 on TCG (but it might just be particular operations... could even be that SSE on TCG is particularly slower)
<klange>
Still need to stick to testing on KVM on the RPi since TCG won't emulate all the cache unhappiness.
<Bitweasil>
On a *real* Rpi? Big spender! :/
<Bitweasil>
I now regret my habit of giving away older Pis to random people.
<Bitweasil>
I'm short of what I want at the moment by several.
<klange>
I got the RPi400 kit.
<Bitweasil>
How's that? I hear the keyboard is on the poor side, but it's a nice little bit of kit.
<klange>
It's a pretty normal compact keyboard. I wouldn't say "poor", but sure it's not as nice as my Surface cover or M1.
<klange>
I like it as a revival of the 80s micro style.
<klange>
And it's definitely better than a PCJr or an Atari 400 :)
<Bitweasil>
*nods*
<Bitweasil>
I know someone with one who complains about the keyboard, but he's... very much a keyboard snob.
<klange>
My main issues with it are the position of the F keys.
<Bitweasil>
"There's nothing wrong with a $500 keyboard you assembled yourself out of a kit, and there's a lot wrong with cheaper ones." So it's hard to really calibrate for him.
<klange>
I have, perhaps famously, said "I could type on a shoe" before.
<klange>
(Gogole "shoe keyboard" and you'll see what I mean)
<zid>
keyboard weirdos always puzzle me, without fail they always like the *worst* keyboards lol
<zid>
"It has 24 missing keys and sounds like a typewriter trying to mate with a wardrobe full of cutlery falling down a staircase"
<Bitweasil>
That would be a good description, yes. :)
<Bitweasil>
I have one of the "New Model Ms" in a partial configuration, but it's for my Rpi.
<klange>
missing 24 keys because it would cost $300 more to have those
<klange>
My main keyboard is a $100 "off the shelf" mechanical, made in Taiwan, sold by a local company, Cherry blue switches. It's a tenkey-less to save desk space and because I found I wasn't actually using the numpad.
<dh`>
my main keyboard is a $10 logitech
<dh`>
every time I've bought anything else I've regretted it
<zid>
I'm on a weird razer, I spent months looking for a keyboard that wasn't ridiculously priced and had things I could *remove* to get a functional keyboard
<zid>
and it isn't even good, it's just.. not horrifically terrible
<klange>
My current keyboard is readily available so if it breaks I can get a new one, if I spill something on it it can be opened easily and bathed in isopropyl and be good to go.
<klange>
And I have done that many times.
<zid>
I *almost* found a good looking keyboard recently
<zid>
but it was £60 and had a wrist wrest and shit if you didn't get the tenkeyless version
<klange>
I don't think I'm particularly clumsy, I just spend so much of my life at my desk that these things are bound to happen.
<zid>
I resent paying extra money to obtain RSI
<klange>
Ah, wait, this one has brown switches, it's the one with numpad I have hooked up to my giant touchscreen that has the blues...
<zid>
wot I want: No awful media keys, no shitty RGB - if it must have it it must be firmware disableable (no shitty 3rd party software), and remember it through power losses so that it doesn't turn my room into a disco if I enter my bios screen
* blockhead
wants to turn his room into a disco now :D
<zid>
good anti ghosting, doesn't have to be perfect, a toggle for normal hid packets and better ones
<zid>
and less than £40
<zid>
so I'm on a razer cynosa, which was the closest thing I found to that, but it still isn't perfect
<zid>
the 10 key packet mode disables the windows key, the paint comes off the keycaps after.. 45 seconds, etc
<zid>
(they're painted so that the shitty rgb can shine through gaps in the paint)
<klange>
isn't that way more than £40, has rgb, and has awful media keys? so it's literally of the things you don't want?