<adder>
wait... it can't be mapped since it's below 1M, meaning pic bad and we want absolute addresses?
Jari-- has quit [*.net *.split]
exit70 has quit [*.net *.split]
FreeFull has quit [*.net *.split]
PublicWiFi has quit [*.net *.split]
Yoofie64 has quit [*.net *.split]
bliminse has quit [*.net *.split]
janemba has quit [*.net *.split]
Opus has quit [*.net *.split]
rom4ik has quit [*.net *.split]
ThinkT510 has quit [*.net *.split]
colona has quit [*.net *.split]
k0valski18891621 has quit [*.net *.split]
fkrauthan has quit [*.net *.split]
wereii has quit [*.net *.split]
night has quit [*.net *.split]
vin has quit [*.net *.split]
jistr has quit [*.net *.split]
moire has quit [*.net *.split]
Mutabah has quit [*.net *.split]
JTL has quit [*.net *.split]
xelxebar has quit [*.net *.split]
Celelibi has quit [*.net *.split]
kristinam has quit [*.net *.split]
chiselfuse has quit [*.net *.split]
foudfou_ has quit [*.net *.split]
gildasio has quit [*.net *.split]
josuedhg has quit [*.net *.split]
sauce has quit [*.net *.split]
khimaros has quit [*.net *.split]
PapaFrog has quit [*.net *.split]
asymptotically has quit [*.net *.split]
hl has quit [*.net *.split]
sham1 has quit [*.net *.split]
exark has quit [*.net *.split]
troseman has quit [*.net *.split]
geist has quit [*.net *.split]
danlarkin has quit [*.net *.split]
nohit has quit [*.net *.split]
kkd has quit [*.net *.split]
les has quit [*.net *.split]
k4m1 has quit [*.net *.split]
ornitorrincos has quit [*.net *.split]
pounce has quit [*.net *.split]
dinkelhacker has quit [*.net *.split]
klys_ has quit [*.net *.split]
amj has quit [*.net *.split]
KitsuWhooa has quit [*.net *.split]
sebastiencs has quit [*.net *.split]
LambdaComplex has quit [*.net *.split]
qookie has quit [*.net *.split]
gog has quit [*.net *.split]
ZipCPU has quit [*.net *.split]
gcoakes has quit [*.net *.split]
antranigv has quit [*.net *.split]
cross has quit [*.net *.split]
MiningMarsh has quit [*.net *.split]
eck has quit [*.net *.split]
lain` has quit [*.net *.split]
zid has quit [*.net *.split]
particleflux has quit [*.net *.split]
chibill has quit [*.net *.split]
woky has quit [*.net *.split]
martylake has quit [*.net *.split]
pieguy128 has quit [*.net *.split]
carrar has quit [*.net *.split]
\Test_User has quit [*.net *.split]
Bitweasil has quit [*.net *.split]
bradd has quit [*.net *.split]
mcfrdy has quit [*.net *.split]
dza has quit [*.net *.split]
DoubleJ has quit [*.net *.split]
valerius_ has quit [*.net *.split]
heat_ has quit [*.net *.split]
nur has quit [*.net *.split]
rustyy has quit [*.net *.split]
frkazoid333 has quit [*.net *.split]
theruran has quit [*.net *.split]
citrons has quit [*.net *.split]
shan has quit [*.net *.split]
lanodan has quit [*.net *.split]
gmodena has quit [*.net *.split]
ramenu has quit [*.net *.split]
Arsen has quit [*.net *.split]
GreaseMonkey has quit [*.net *.split]
zhiayang has quit [*.net *.split]
cuppajoeman has quit [*.net *.split]
rselim has quit [*.net *.split]
vismie has quit [*.net *.split]
gjn has quit [*.net *.split]
hanemile has quit [*.net *.split]
nagitsu has quit [*.net *.split]
staceee has quit [*.net *.split]
patwid has quit [*.net *.split]
thaumavorio has quit [*.net *.split]
raggi has quit [*.net *.split]
FireFly has quit [*.net *.split]
energizer has quit [*.net *.split]
xenos1984 has quit [*.net *.split]
Bonstra has quit [*.net *.split]
Ermine has quit [*.net *.split]
randm has quit [*.net *.split]
Matt|home has quit [*.net *.split]
gimli has quit [*.net *.split]
gruetzkopf has quit [*.net *.split]
bslsk05 has quit [*.net *.split]
alethkit has quit [*.net *.split]
torresjrjr has quit [*.net *.split]
exec64 has quit [*.net *.split]
sm2n has quit [*.net *.split]
ddevault has quit [*.net *.split]
xtex has quit [*.net *.split]
yuiyukihira has quit [*.net *.split]
basil has quit [*.net *.split]
Rubikoid has quit [*.net *.split]
alpha2023 has quit [*.net *.split]
dostoyevsky has quit [*.net *.split]
khrbtxyz has quit [*.net *.split]
XgF has quit [*.net *.split]
bleb has quit [*.net *.split]
Irvise_ has quit [*.net *.split]
blockhead has quit [*.net *.split]
pitust has quit [*.net *.split]
nikolar has quit [*.net *.split]
dzwdz has quit [*.net *.split]
nikolapdp has quit [*.net *.split]
mjg has quit [*.net *.split]
Goodbye_Vincent has quit [*.net *.split]
teroshan has quit [*.net *.split]
dequbed has quit [*.net *.split]
HumanG33k has quit [*.net *.split]
thinkpol has quit [*.net *.split]
snappy has quit [*.net *.split]
eschaton has quit [*.net *.split]
sortie has quit [*.net *.split]
MrBonkers has quit [*.net *.split]
brynet has quit [*.net *.split]
leon has quit [*.net *.split]
j`ey has quit [*.net *.split]
phr3ak has quit [*.net *.split]
edr has quit [*.net *.split]
Turn_Left has quit [*.net *.split]
Terlisimo has quit [*.net *.split]
Ram-Z has quit [*.net *.split]
bauen1 has quit [*.net *.split]
linear_cannon has quit [*.net *.split]
mahk has quit [*.net *.split]
immibis has quit [*.net *.split]
stux has quit [*.net *.split]
LittleFox has quit [*.net *.split]
jjuran has quit [*.net *.split]
pg12 has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
jbowen has quit [*.net *.split]
elfenix|cloud has quit [*.net *.split]
qxz2 has quit [*.net *.split]
Ameisen has quit [*.net *.split]
cultpony has quit [*.net *.split]
froggey has quit [*.net *.split]
kline has quit [*.net *.split]
andreas808 has quit [*.net *.split]
JerryXiao has quit [*.net *.split]
smeso has quit [*.net *.split]
tjf has quit [*.net *.split]
meisaka has quit [*.net *.split]
m3a has quit [*.net *.split]
mavhq has quit [*.net *.split]
pdziepak has quit [*.net *.split]
azonenberg has quit [*.net *.split]
Patater- has quit [*.net *.split]
terrorjack has quit [*.net *.split]
CompanionCube has quit [*.net *.split]
Stary has quit [*.net *.split]
stefanct has quit [*.net *.split]
melonai has quit [*.net *.split]
V has quit [*.net *.split]
marshmallow has quit [*.net *.split]
nshp has quit [*.net *.split]
Reinhilde has quit [*.net *.split]
hirigaray has quit [*.net *.split]
alice has quit [*.net *.split]
cheapie has quit [*.net *.split]
ChanServ has quit [*.net *.split]
m5zs7k has quit [Max SendQ exceeded]
JerryXiao has joined #osdev
heat_ has joined #osdev
Bonstra has joined #osdev
qookie has joined #osdev
gog has joined #osdev
[Kalisto] has joined #osdev
josuedhg has joined #osdev
nur has joined #osdev
Terlisimo has joined #osdev
rustyy has joined #osdev
frkazoid333 has joined #osdev
Turn_Left has joined #osdev
edr has joined #osdev
Ermine has joined #osdev
ZipCPU has joined #osdev
smeso has joined #osdev
khimaros has joined #osdev
foudfou_ has joined #osdev
theruran has joined #osdev
citrons has joined #osdev
bauen1 has joined #osdev
gcoakes has joined #osdev
amj has joined #osdev
randm has joined #osdev
linear_cannon has joined #osdev
tjf has joined #osdev
Matt|home has joined #osdev
mahk has joined #osdev
antranigv has joined #osdev
meisaka has joined #osdev
pitust has joined #osdev
m3a has joined #osdev
nikolar has joined #osdev
asymptotically has joined #osdev
cross has joined #osdev
dzwdz has joined #osdev
stux has joined #osdev
MiningMarsh has joined #osdev
immibis has joined #osdev
mjg has joined #osdev
chiselfuse has joined #osdev
hl has joined #osdev
LittleFox has joined #osdev
shan has joined #osdev
nikolapdp has joined #osdev
mavhq has joined #osdev
Goodbye_Vincent has joined #osdev
pdziepak has joined #osdev
azonenberg has joined #osdev
gildasio has joined #osdev
gruetzkopf has joined #osdev
teroshan has joined #osdev
eck has joined #osdev
bslsk05 has joined #osdev
terrorjack has joined #osdev
jjuran has joined #osdev
Patater- has joined #osdev
torresjrjr has joined #osdev
alethkit has joined #osdev
sm2n has joined #osdev
exec64 has joined #osdev
ddevault has joined #osdev
xtex has joined #osdev
yuiyukihira has joined #osdev
basil has joined #osdev
lain` has joined #osdev
zid has joined #osdev
lanodan has joined #osdev
sham1 has joined #osdev
Rubikoid has joined #osdev
gmodena has joined #osdev
particleflux has joined #osdev
dequbed has joined #osdev
ramenu has joined #osdev
GreaseMonkey has joined #osdev
HumanG33k has joined #osdev
sauce has joined #osdev
chibill has joined #osdev
PapaFrog has joined #osdev
elfenix|cloud has joined #osdev
exark has joined #osdev
pg12 has joined #osdev
CompanionCube has joined #osdev
Stary has joined #osdev
martylake has joined #osdev
Arsen has joined #osdev
woky has joined #osdev
alpha2023 has joined #osdev
stefanct has joined #osdev
troseman has joined #osdev
pieguy128 has joined #osdev
carrar has joined #osdev
thinkpol has joined #osdev
\Test_User has joined #osdev
MrBonkers has joined #osdev
zhiayang has joined #osdev
nshp has joined #osdev
nohit has joined #osdev
geist has joined #osdev
danlarkin has joined #osdev
kkd has joined #osdev
cuppajoeman has joined #osdev
jbowen has joined #osdev
eschaton has joined #osdev
snappy has joined #osdev
SanchayanMaity has joined #osdev
sortie has joined #osdev
qxz2 has joined #osdev
bradd has joined #osdev
Bitweasil has joined #osdev
marshmallow has joined #osdev
vismie has joined #osdev
les has joined #osdev
gjn has joined #osdev
rselim has joined #osdev
nagitsu has joined #osdev
hanemile has joined #osdev
patwid has joined #osdev
staceee has joined #osdev
Ameisen has joined #osdev
k4m1 has joined #osdev
ornitorrincos has joined #osdev
Ram-Z has joined #osdev
thaumavorio has joined #osdev
brynet has joined #osdev
dza has joined #osdev
dostoyevsky has joined #osdev
mcfrdy has joined #osdev
leon has joined #osdev
XgF has joined #osdev
khrbtxyz has joined #osdev
pounce has joined #osdev
melonai has joined #osdev
V has joined #osdev
hirigaray has joined #osdev
dinkelhacker has joined #osdev
cultpony has joined #osdev
DoubleJ has joined #osdev
froggey has joined #osdev
raggi has joined #osdev
gimli has joined #osdev
bleb has joined #osdev
kline has joined #osdev
valerius_ has joined #osdev
FireFly has joined #osdev
andreas808 has joined #osdev
klys_ has joined #osdev
Reinhilde has joined #osdev
Irvise_ has joined #osdev
alice has joined #osdev
cheapie has joined #osdev
KitsuWhooa has joined #osdev
energizer has joined #osdev
ChanServ has joined #osdev
phr3ak has joined #osdev
LambdaComplex has joined #osdev
j`ey has joined #osdev
sebastiencs has joined #osdev
blockhead has joined #osdev
slow99 has quit [Max SendQ exceeded]
asarandi has quit [Max SendQ exceeded]
duckworld has quit [Ping timeout: 264 seconds]
m5zs7k has joined #osdev
slow99 has joined #osdev
asarandi has joined #osdev
Jari-- has joined #osdev
exit70 has joined #osdev
FreeFull has joined #osdev
Yoofie64 has joined #osdev
PublicWiFi has joined #osdev
bliminse has joined #osdev
janemba has joined #osdev
rom4ik has joined #osdev
Opus has joined #osdev
ThinkT510 has joined #osdev
colona has joined #osdev
wereii has joined #osdev
fkrauthan has joined #osdev
k0valski18891621 has joined #osdev
night has joined #osdev
vin has joined #osdev
jistr has joined #osdev
JTL has joined #osdev
xelxebar has joined #osdev
Celelibi has joined #osdev
kristinam has joined #osdev
moire has joined #osdev
Mutabah has joined #osdev
PapaFrog has quit [Server closed connection]
PapaFrog has joined #osdev
pax_73 has quit [Ping timeout: 240 seconds]
josuedhg has quit [Quit: Client closed]
pax_73 has joined #osdev
JTL has quit [Remote host closed the connection]
JTL1 has joined #osdev
josuedhg has joined #osdev
josuedhg has quit [Client Quit]
heat_ has quit [Remote host closed the connection]
heat_ has joined #osdev
xenos1984 has joined #osdev
<adder>
this is it: 0x00000000001022ba: addr16 mov 0x24(%si),%eax
<adder>
never wrote this line
<adder>
it's a part of longmode: ...
gog has quit [Quit: byee]
X-Scale has joined #osdev
Gooberpatrol66 has joined #osdev
Jari-- has quit [Remote host closed the connection]
vai has joined #osdev
vai is now known as Jari--
duckworld has joined #osdev
* adder
ragequits
sauce has quit [Server closed connection]
sauce has joined #osdev
Turn_Left has quit [Read error: Connection reset by peer]
<Mutabah>
`addr16` but you mentioned long mode, are you sure that disassembly is correct?
<geist>
that looks like an address
<geist>
like a 64bit address to something just inside 1MB that is being interpreted as an instruction
<Mutabah>
the address looks sensible enough for kernel code to me?
<Mutabah>
(For early boot at least, before the jump to upper memory)
<geist>
right
<geist>
like an address of a function at just over 8K into 1MB, where the code may be linked to run at
edr has quit [Quit: Leaving]
vdamewood has joined #osdev
X-Scale has quit [Quit: Client closed]
Jari-- has quit [Ping timeout: 264 seconds]
Arthuria has joined #osdev
X-Scale has joined #osdev
zhiayang has quit [Quit: oof.]
<heat_>
IMO that instruction looks super garbage
<heat_>
probably 32-bit code interpreted as 64-bit? or vice-versa
<geist>
well yeah it's not an instruction
<geist>
it's an address
<heat_>
oh haha well spotted
<kof673>
sham1: you can chant now
<zid>
64 as 32 was my guess, given he said it was what was at longmode:
* sham1
chants
vinleod has joined #osdev
vdamewood has quit [Ping timeout: 260 seconds]
vinleod is now known as vdamewood
<zid>
which turns it into mov eax, [esp-0x3d]
<zid>
or something
<zid>
depending what's next, I think the -3d is actually the ret
<zid>
ye it is
<zid>
gas says addr 16 mov eax, [si+0x24] is 67 7b 44 24, 67 7b 44 24 as amd64 is mov eax, [esp+n] with the n byte missing
<zid>
which is exactly what you'd expect to see if he did what he said he did
<heat_>
day 2(3?) of fucking around with a linux style page table system
<heat_>
lots of helpers are needed, but helpers i probably could've used earlier...
JTL1 is now known as JTL
Arthuria has quit [Ping timeout: 268 seconds]
gcoakes has quit [Ping timeout: 252 seconds]
heat_ has quit [Ping timeout: 268 seconds]
<adder>
pleased to announce that I wiped out my first attempt at writing a kernel
<adder>
now using limine. I see gdt is loaded, so are CRs, so I suspect remap 8259, load idt, then what? What part of paging is implemented, not sure what I need to do
<geist>
start getting interrupts working
<adder>
sounds like a good idea
<Mutabah>
limine likely leaves you with paging enabled, but with an identity mapping
<Mutabah>
so you need to set up your on structures to move the kernel to upper memory and prepare for userland
<adder>
I think I've seen they mention higher half kernel
<adder>
"It provides cutting edge features such as 5-level paging support, 64-bit Long Mode support, and direct higher half kernel loading."
<geist>
cutting edge!
<adder>
:)
<geist>
ut anyway, at this point you should decide what you want to do
<geist>
and then work backwards from that
goliath has joined #osdev
rustyy has quit [Quit: leaving]
MrCryo has joined #osdev
<chiselfuse>
the (R)eadable bit in a code segment descriptor is ignored in Long mode. does that mean that a code segment is forced to always be readable and can't be set to be otherwise?
<zid>
Is there a point to -R segments at all?
<zid>
maybe as a quick hack to disable some chunk of memory in an atomic/fast way?
<kazinsal>
not that I can think of
<geist>
X only has some advantages, but x86 doesn't support it, no
<geist>
riscv and arm have X only page mappings though
<zid>
what's the point I am missing?
<zid>
causing a fault on a slightly stray pointer is about all I can think of
<geist>
for what?
<zid>
-R
<zid>
+X-R
<geist>
yeah there's some security bits to it
<geist>
not a giant thing, but it's sort of lie ASLR, you can make slightly more secure code if you cant even read from it
<geist>
iirc clang or whatnot has support for it, but it's only supported on some arches
<zid>
seems like a waste of a bit, that's incredibly weak as a protection, can't think of an exploit I've ever seen that needed it
<geist>
zid has spoken
<zid>
what
<geist>
it depends on how the encoding is done really
<Matt|home>
o\
<zid>
why am I getting abuse for saying I think that seems pretty weak?
<geist>
different arches decode permissions differently, so depends. riscv for example encodes page table permissions as literally RWX, 3 bits
<geist>
so it's just one of the variants
<chiselfuse>
what position in the descriptor would the bit have to be encoded in in order for it to be dangerous geist
<geist>
the only one RV doesn't really support is W only
<geist>
dangerous?
<zid>
page table bits tend to get more and more loaded up in meanings and eventually run short, if x86 is anything to go by, they've already started stealing address bits (NX)
<chiselfuse>
what depends on the encoding then? geist> it depends on how the encoding is done really
<geist>
of course arm and riscv (and pretty much everything else) doesn' thave the segment descriptors anywy, so it's entirely page table perms
<geist>
chiselfuse: oh what i mean twas how it is encoded may determine, IMO, if it's a 'waste' of a bit
<kazinsal>
I can see --x code segments being slightly more secure than r-x code segments for kernel code if the kernel also goes through painstaking efforts to hide itself on disk
<geist>
as in, it may just naturally fall out of the way perms are encoded, or not. in the case of X86 it doesn't really
<zid>
You can pick a *different* encoding if you don't have to support -R though, if you added it you already wasted it
<chiselfuse>
but point is that that all code segments are forced to be readable in longmode, right?
<geist>
yes
<geist>
but also remember x86 adds page table permissions on top of it
<zid>
yea nobody actually uses segmented memory
<zid>
you're going surprisingly deep into this
<geist>
really the other way of looking at it is segment dscriptors in long mode are basically nerfed, permission wise. nothing interesting is done there, except to actually just determine if it's 64bit and code vs data
<chiselfuse>
i mean, you're forced to use the permissions set in CS
<geist>
and then all permissios really come from the page table bits
<geist>
except, as you point out, it's forced to be R
<geist>
because it's basically unused
<kazinsal>
the selector itself really doesn't matter much
<kazinsal>
there are only a handful of permutations for 64-bit selectors
<geist>
ie, the permission bits in the long mode descriptors dont do anything, on purpose, by design. as a way of basically nerfing them to be not useful
<chiselfuse>
geist: and if the page permission of a code segment is -R then what happens
<geist>
ie yo uhave to load the GDT because you might load a 32bit or whatnot segment into it, but for pure 64bit you're just setting a bit pattern in the segment descriptor that says '64bit code' and that's it
<geist>
t's probaly illegal. look at the manual
<geist>
may be ignored, may be MBZ, i forget
<chiselfuse>
i just wanted to know whether they're expressing the same thing or if they were orthogonal
<geist>
or the R bit means something else for code descriptors? I honestly dont remember off the top of my head
<geist>
this is described in the intel and amd manuals in great detail
<zid>
bear in mind that you're forced to use 'all of memory' selectors
<bslsk05>
www.sandpile.org: sandpile.org -- x86 architecture -- descriptors
<chiselfuse>
geist: "The readable (R) and accessed (A) attributes in the type field are also ignored." is all in the current amd manual page i'm reading
<zid>
so paging definitionally only applies to a subset, and has to function, so you can figure out what order things must work in
<kazinsal>
selectors are only fun to fiddle with weird bit combinations in 16 and 32 bit modes
<kazinsal>
I think openbsd/i386 still uses segment limits to implement W^X
<kazinsal>
on non-NX systems
<geist>
oh you know what, pre long mode you *can* encode a X only permission
<geist>
looking at the intel manual now
<kazinsal>
huh
<kazinsal>
funny that they didn't carry that over
<geist>
0 0 0 for C R A seems to be execute only
<zid>
yea, that's where we started, R is ignored in long mode, does that mean everything is +R
<chiselfuse>
geist: that holds for long mode too
<chiselfuse>
i think...
<chiselfuse>
no wait nvm i'm confusing things
<geist>
the intel manual seems to very confusingly present this
<geist>
it basically says here's all the bits, oh and also if uo're in ia32e mode L means long mode
<geist>
so the AMD manual says very clear what's going on
<zid>
intel manual we found also refuses to acknowledge fsbase, the only actual mention of it is in the tss psuedocode for a task gate I think, I discovered earlier
<geist>
thsi is a case where the AMD manual > intel manual
<zid>
for saving it
<geist>
so that straight up answers it: R is ignored
<kazinsal>
yep I'd trust the verdict of the amd manual here
<chiselfuse>
geist: the info of whether a segment is "execute" seems to come from whether it is pointed to by CS or otherwise
<zid>
well code fetches happen through cs
<zid>
so anything cs can access, is not a #GP
<kazinsal>
also bit 11 needs to be set for it to be a code descriptor
<kazinsal>
so consider that your X bit
<kazinsal>
or is it 10
<zid>
if your cs were -x it would fault 100% of the time, seems like one of those things they'd make #GP just for trying to load it
<geist>
i thin it's 11
<geist>
the C bit is 'conforming' which means something i forget
<chiselfuse>
C and R become E and W for non-code segment descriptors
<kazinsal>
soemthing about cross-RPL calls
<kazinsal>
I think
<kazinsal>
can't remember how it works
<geist>
yah
<zid>
conforming means you can run them at the 'wrong' priv level, afaik
<kazinsal>
because descriptors have been pretty much set and forget since the 386
<zid>
I think it's designed for like, vdso type stuff
<kazinsal>
apart from aforementioned weirdness like openbsd/i386 setting up new user mode base/limits on context switches
<chiselfuse>
Conforming (C) Bit. Bit 10 of the upper doubleword. Setting this bit to 1 identifies the code segment as conforming. When control is transferred to a higher-privilege conforming code-segment (C=1) from a lower-privilege code segment, the processor CPL does not change. Transfers to non-conforming code-segments (C = 0) with a higher privilege-level than the CPL can occur only through gate descriptors.
<geist>
the key was before all of this, bit 21 was unused. and so they had one bit left, and they turend that into the L bit
<chiselfuse>
See “Control-Transfer Privilege Checks” on page 109 for more information on conforming and non-conforming code-segments.
<kazinsal>
16-bit protected mode code tended to make fairly heavy use of LDTs
<kazinsal>
on account of only having sixteen bits of virtual address space to work with
<geist>
i've always found the AMD manual is more clear with all this stuff. the intel manual tends to be written in the order the cpus were released, so it'll talk aabout all the stuff for 286, then 386, then say 'oh and then there's this long mode that modifies everything you just read'
<geist>
like they didn't go back and re-edit the thnig
<kazinsal>
yeah
<geist>
whereas the AMD manual tends to present it all as one thing, so it's a bit more cohesive
<zid>
yea intel manual needs a good cleanup, but that's a hard sell internally I imagine
<kazinsal>
they can't figure out how to fab chips that don't spontaneously combust. their documentation team probably got fired a decade ago
<kazinsal>
the high end raptor lake chips are nearing recall territory
<geist>
yah ive been reading intel mauals for nearly 30 years now and it really hasn't changed much, just more stuff added
<geist>
no real rewrites. my old 1996 pentium pro manual has basically the same text just minus new stuff
<kazinsal>
the pre-pentium manuals are good fun to read
<kazinsal>
I've got the 80386 one around here somewhere and it's extremely detailed
<geist>
yeah same
<geist>
got it used off amazon
<chiselfuse>
kazinsal: can you give me the exact title of this 80386 one?
<chiselfuse>
how is it different than the regular intel manuals?
<kazinsal>
I'd have to go find it but it differs on account of being almost 40 years old
<kazinsal>
I have a number of job-irrelevant books at the office so no one tries to use my desk as a hot desk
<chiselfuse>
kazinsal: do you use it for your job?
<chiselfuse>
oh i just read last message
<kazinsal>
both the windows internals 7th edition books, both volumes of Routing TCP/IP by cisco press
<kazinsal>
it's just for show mostly
<chiselfuse>
hacker desk
<kazinsal>
I work for a university so we have some co-op students who are in more frequently than I am
<geist>
yah sae, i have the VAX manual here, kinda a show off
<geist>
though it doesn't really work, because no one has the faintest clue what a vax is
<kazinsal>
and if you don't thoroughly display your ownership of the desk they'll end up using it to reflash a bunch of laptops
<kazinsal>
so there's books and a couple framed photos and a yeti tumbler
<kazinsal>
and a big fuckoff sign that says TROY MARTIN | SENIOR SYSTEM ADMINISTRATOR
<geist>
haha yeah, if you dot cover your desk someone assumes it's not in use
<kazinsal>
though this wednesday one of my colleagues came in after taking two weeks off and found someone had fucked with his chair... despite one of his framed things on his desk being a 25-year service award
<Mutabah>
Three plushies, two minis, and three old cameras :D
<chiselfuse>
what did they do to the chair
<kazinsal>
messed with the lumbar or something
<geist>
or someone messes with your monitor, i hate that
<geist>
i have it just so
<kazinsal>
oh yeah
<kazinsal>
I wrote down the colour calibration numbers for my monitors at the office
<kazinsal>
just so no one can mess with them
<chiselfuse>
i'd just put a very thin wire all over the desk edges and connect it to low current supply tbh. ornamenting the thing with stuff that collects dust and gives you a sense of disorder just to deter people meh
<kazinsal>
even with the union I think I'd get fired for that
<chiselfuse>
kazinsal: not if you explain to them that the wire is there for ornament and that it coincidentally happens to touch the computer case externally which happens not to be grounded properly which overall you cba to fix
<geist>
no you cant electrocute your cow-orkers
<geist>
that'll get you a chat with HR
<kazinsal>
plus I don't want to trouble my shop steward. she's nice and it'd be like an hour drive to the campus my office is at
<bslsk05>
github.com: linux-kernel-2.5/arch/x86_64/boot/bootsect.S at master · duqi007/linux-kernel-2.5 · GitHub
X-Scale has quit [Quit: Client closed]
X-Scale has joined #osdev
hwpplayer1 has quit [Read error: Connection reset by peer]
<heat>
Ermine, you don't need it
<netbsduser>
dostoyevsky2: this is why i went for limine
<heat>
dostoyevsky2, haha 1) linux 2.5 2) the boot sector is a very small part of the boot code
<netbsduser>
i like the amd64 on the whole but i don't care much for getting myself into a sensible state on it
<heat>
x86_64 linux has some 3 or 4 separate boot paths for commodity hardware, depending on the setup
<netbsduser>
i think 32-bit x86 is targeted mostly because old tutorials (often of dubious quality) target it
<heat>
i would not target x86_64 on a new tutorial
FreeFull has quit []
<netbsduser>
why not? riscv and aarch64 are minefields of proprietary specificities
<heat>
paging is such a brilliant hard to understand thing that starting off with "hey lets decode this 4 level maybe 5 level complex structure that transparently transforms your memory accesses"
<dostoyevsky2>
netbsduser: Ah, limine is interesting
<heat>
riscv and aarch64 at least have the property of actually supporting nommu
<heat>
you can boot at your own pace
<netbsduser>
if i can't have an MMU i don't want it
<heat>
meanwhile in x86_64 part 0 needs to be a speedrun on the x86 architecture up to 2001
<netbsduser>
my kernel started as the support code for an implementation of what's described in the mach vm paper
<heat>
paging, gdt, possibly a dummy idt (all in 32-bit assembly ofc), poking msrs, doing a complicated dance using cr0 and cr3, switching processor modes, reloading a new gdt, and finally fucking jumping to C
<netbsduser>
this is why i opted for limine to avoid that
<heat>
you could write most of the above in C, but that falls into the dark arts of writing position-independent C using gcc/clang
navi has quit [Quit: WeeChat 4.2.1]
X-Scale has quit [Ping timeout: 250 seconds]
FreeFull has joined #osdev
<dostoyevsky2>
netbsduser: isn't there something like a minimal x64 bootloader? I see limine also has a boot menu, which is great, but also kind of makes it hard to see the essential parts
xenos1984 has quit [Ping timeout: 240 seconds]
Jari-- has quit [Ping timeout: 272 seconds]
xenos1984 has joined #osdev
obrien has quit [Remote host closed the connection]
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 268 seconds]
Left_Turn has joined #osdev
X-Scale has joined #osdev
Turn_Left has quit [Ping timeout: 272 seconds]
X-Scale has quit [Ping timeout: 250 seconds]
X-Scale has joined #osdev
navi has joined #osdev
navi has quit [Client Quit]
gcoakes has quit [Ping timeout: 264 seconds]
Jackneill has joined #osdev
xenos1984 has quit [Ping timeout: 256 seconds]
gog has joined #osdev
X-Scale has quit [Quit: Client closed]
xenos1984 has joined #osdev
navi has joined #osdev
<chiselfuse>
i learned that every memory access (even RIP) happens through segmentation on x86. what segment does `mov [rbp+0x8], rax` use? it puts the value of `rax` into the memory location pointed to by address calculated by: <base address of some segment> + rbp + 0x8. in long mode, what segment is it?
<Ermine>
so it's not necessary to do paging on aarch64?
kof673 has joined #osdev
<GeDaMo>
chiselfuse: in 64 bit mode, segments aren't really a thing
<heat>
Ermine, no, not strictly required. but required if you want to e.g get caching
<GeDaMo>
Only fs and gs have uses, all the others are based at 0 and cover all of memory
<chiselfuse>
GeDaMo: they are though, even RIP is really CS:RIP even though its base address is always 0
<chiselfuse>
GeDaMo: AFAIU the CS in CS:RIP is still relevant because there are some flags that can change in its segment selector
<GeDaMo>
I'm pretty sure that mov will use ds by default
<chiselfuse>
GeDaMo: i just want to know which segment register that instruction i posted uses
<chiselfuse>
hmm
<Ermine>
chiselfuse: CS:RIP = RIP if base is 0
<Ermine>
for data accesses it's DS
<chiselfuse>
not SS? since rbp is used for stack
<Ermine>
or SS... idk
<heat>
it really doesnt matter
<Ermine>
^
<Ermine>
your base is 0
<heat>
SS = DS = ES = CS in x86_64
<gog>
the only segments whose bases are relevant in long mod are FS and GS
<gog>
and even then we have instructions to deal with those indirectly now
<GeDaMo>
I said that! :P
<gog>
oh hi GeDaMo
<gog>
:D
<chiselfuse>
heat: and yet the manual makes a distinction between segment descriptors of code segments vs data segments for long mode
<gog>
so you did
<chiselfuse>
i don't care about base address
<heat>
yes it does
kof673 has quit [Ping timeout: 264 seconds]
<heat>
you can't execute when cs = a data segment
<chiselfuse>
i know it's all zero except for fs and gs
<heat>
that's literally the only difference
<heat>
nothing else matters
<Ermine>
so you set proper selectors in ds and cs and that's all
<Ermine>
the fact that x86(_64) is a mess is not news
<chiselfuse>
what's the harm in knowing what the cpu uses for `mov [rbp+0x8], rax` even if it doesn't matter
<heat>
i just found it independently. probably because most programs i run are single threaded
<heat>
the big problem would be that you could observe stale data
obrien has joined #osdev
<geist>
yeah sounds lje yiou need to write some directed testing that tries to incover this sort of thing
<dinkelhacker>
Can you do (relative) performance testing with qemu?
<heat>
with kvm totally
<dinkelhacker>
but that would mean only for my host architecture, right?
<heat>
yep
<kazinsal>
cross-arch performance testing is Complicated
<dinkelhacker>
hm and without would you say it is complete bs or could you still see if something performs better than another thing?
<heat>
your performance will in no way mirror a real CPU
<heat>
well, in no *guaranteed* way
<dinkelhacker>
that would be fine as long as it would mean that i could still see if something is twice as fast... But i guess I can't be sure?
<heat>
i'd say it heavily depends on what you're doing
<heat>
like going from O(n) to O(1) will be visible in qemu tcg
<heat>
but, depending on how tcg does codegen, going from a linked list to a std::vector might not
<heat>
also AFAIK qemu tcg multi core is kind of iffy
<dinkelhacker>
Hm... That kind of expected this answer. Guess I'll have to buy some hardware.
<dinkelhacker>
heat: thx!
mavhq has joined #osdev
josuedhg has quit [Quit: Client closed]
<geist>
yah +1 to what heat said
vdamewood has joined #osdev
X-Scale has joined #osdev
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
gcoakes has quit [Ping timeout: 272 seconds]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
<nikolapdp>
heat what do you mean `kind of iffy`
<geist>
how qemu emulates multi core is version and arch specific, for one thing
<geist>
some combinations of versions and arches, its actually only running a single host thread and round robining bertween emulated cpus, for example, which would completely screw up any sort of benchmarking
<geist>
it's possible that may no longer be the case in current tip of tree qemu for all arches, but i honestly dunno
<nikolapdp>
huh interesting
<heat>
yeah, also i've heard of weird stalls/performance problems on multi-cored qemu tcg vms that were *solved* by forcing single thread
<geist>
even if it's running full multitread there are a lot of cases where the host threads have to synchronize
<geist>
TLB shootdowns cross core, etc
<geist>
or some atomic stuff, depending o the combination of host and target
netbsduser has quit [Ping timeout: 256 seconds]
<zid>
chiselfuse: We had someone at some point with a fun bug where certain lines of C were doing the complete wrong thing for some reason
<zid>
mainly seemed to be weirdness with passing parameters
<zid>
turned out their ds and ss were different, so push eax; and mov [stack], eax were giving different results
netbsduser has joined #osdev
<nikolapdp>
heh nice
<gog>
oops
<zid>
nikolapdp is it monday yet
<nikolapdp>
no
<zid>
fuk
<gog>
just another manic monday
<gog>
wish it was sunday
<gog>
'cause that's my funday
<gog>
my i-don't-have-to-run-day
<zid>
why would you run on any day
<zid>
I wouldn't run even if there was lava coming at me
<heat>
gog do you have that dawg in you
<heat>
i think you clearly don't because dawgs love running
<gog>
why must i be like that why must i chase the cat
<gog>
nothin but the dawg in me
<netbsduser>
i couldn't forget about tlb flushing, it's incredible how slow things are with a few cores under qemu amd64 when i give little memory (which i do as standard to exercise page replacement and give me early indication of something going awry there)
<gog>
did i tell you i was sining atomic dawg or something
<netbsduser>
the m68k port is blazing fast by comparison
<heat>
wow little memory?
<heat>
how*
<Ermine>
sawg
<Ermine>
dawg
<netbsduser>
6m on m68k, 14 amd64
<netbsduser>
about the minimum with which i can boot and load a program
<heat>
that's tight
<netbsduser>
it should be possible to tighten it further, i am checking now and only about 950 pages of kernel wired memory are used on m68k to boot and run a program which spawns a few threads and loops forever
<netbsduser>
about half of which are the virtio-gpu framebuffer, but we can exclude those from the count
<heat>
plus whatever weird random page allocations i have that i'm not accounting for
<heat>
somehow adds up to 20M
<netbsduser>
it looks like the bare minimum i can have on m68k is 175 pages if i want boot to not proceed at a literally glacial pace and to frequently trip areas where i don't yet handle physical page shortage properly
<heat>
<6>[ 4.513733] kmalloc-131072 131072 size 0 full 0 free 1 partial 1 active objs 131072 total obj size ~1052672 total slab size
<heat>
gotta love these one-off allocations
<netbsduser>
when i start getting things to web scale levels (slab magazines and so on) i expect to be requiring a bit more memory on smp systems
<heat>
but will you run mongodb??
<netbsduser>
of course i will
<netbsduser>
it is web scale
m3a has joined #osdev
<heat>
day 3 of linux-like page table styling: *lots* of wrappers, but the promise of avoiding duplicating tricky logic is still very enticing to me
<netbsduser>
what are you plotting
<netbsduser>
i also moved over to a linuxish approach to the page tables
<netbsduser>
that makes a vax port trickier unfortunately but swings and roundabouts
<heat>
i want to remove my pmap duplication across archs by having a unified page table scheme (with pgd_t, p4d_t, pud_t, etc)
<heat>
end goal is to also remove the amaps and store anon memory/swap info directly in page tables
<netbsduser>
i had similar goals
<netbsduser>
the only particular annoyance was the 68040 MMU has page tables not page sized and i like to allocate those in multiples to make up a page's worth
obrien has quit [Remote host closed the connection]
<heat>
is that work on your master branch?
<heat>
oh, tables.c probably
netbsduser has quit [Ping timeout: 260 seconds]
X-Scale has quit [Ping timeout: 250 seconds]
<chiselfuse>
zid> turned out their ds and ss were different, so push eax; and mov [stack], eax were giving different results
<chiselfuse>
but `push eax` means "put eax in ss:rsp and decrement rsp", `mov [rsp], eax` means "put eax in ss:rsp"... both use `ss` implicitly, not `ds`. can you clarify?
hwpplayer1 has quit [Quit: sleep ZZZzZZZZZ!....]
kof673 has joined #osdev
MrCryo has joined #osdev
X-Scale has joined #osdev
MrCryo has quit [Ping timeout: 260 seconds]
joe9 has joined #osdev
<geist>
the default segment register for *bp and *sp is ss, everything else is ds