IRC channel logs
2023-08-18.log
back to list of logs
<damo22>i ran out of rabbits to pull out of my hat <damo22>solid_black: how is %gs supposed to work on x86_64 ? <damo22>does MSR 0xc0000100 101 and 102 work on intel? <solid_black>there's an MSR for GS_BASE, and one for KERNEL_GS_BASE <solid_black>you write stuff there, then you can do %gs:offset to access stuff at *(base + offset) <solid_black>then there's swapgs to atomically swap the two msr's values <solid_black>which you're supposed to do when entering/existing the kernel <solid_black>except you have to be really really careful with it, apparently <damo22>i cant use kernel_gs_base on i386 <damo22>i can wait until it works out of the box <damo22>i need to figure out why smp is so slow <damo22>i suppose when 64 bit lands, we will discontinue i386? <solid_black>and Samuel has previously said we're not going to, but we're not going to deal with 2038 problem either <damo22>maybe i cant fix i386 properly unless i use %gs <damo22>since the msr is 64 bit wide, doesnt that mean you can store a 64 bit address in the gs_base and kernel_gs_base ? <damo22>so it can be any kalloc'd address <damo22>why does the gs:0 need to store a pointer to itself? <solid_black>see, there's no way (other than reading from MSR) to actually get the base <damo22>so you just put a pointer to the struct as the first member <solid_black>so either you always specify an offset when trying to access things (but that quickly gets awkward when you want the data to be a real structure), or you store self-pointer at a known offset and then read that <solid_black>also in userspace that is a requirement per x86_64 TLS ABI <solid_black>hm interesting, so from quickly glancing at linux source, they seem to be setting up the descriptors/GDTs (I have little idea how this works) for each CPU separately on i386, so they can load a fixed value into %gs and have it point into the percpu area <damo22>is %gs unused for anything else on i386? <solid_black>you should assume both %fs and %gs are used by userspace <solid_black>so you cannot clobber their values as far as userland is concerned <damo22>but its simple enough to save thse <solid_black>in fact the code might already be saving them, not sure <solid_black>except that to save your gs value (and others) there, you should get a pointer there, somehow <solid_black>to spill %gs onto the stack first, load your per-cpu structure, find the i386_saved_state, and then save gs there <damo22>i386_saved_state should have per cpu gs slots <solid_black>and you should coordinate this with Luca, he understands this much better than me <solid_black>userspace expects to keep the same gs value even if the thread gets migrated to another cpu, for example <damo22>well that sucks, you could use the msr <damo22>i dont know if i can be bothered working it out <solid_black>note that this is from a commit before i686 support was removed