IRC channel logs
2020-05-01.log
back to list of logs
<almuhs>youpi: somethink like this? rsdt = pmap_get_mapwindow(INTEL_PTE_R(rsdt_phys)); <youpi>that's the function yes, but look at what it returns <almuhs>in pmap.h appears many others INTEL_PTE <damo22>i did something similar to pmap_map_bd <almuhs>the function returns "pmap_mapwindow_t" <almuhs>static pmap_mapwindow_t mapwindows[PMAP_NMAPWINDOWS]; <almuhs>"Two slots for temporary physical page mapping, to allow for physical-to-physical transfers." <damo22>the way i did it was using vremap from linux/ code to map everything i needed to virtual addresses <almuhs>damo22: but that is a very dirty wat <damo22>but i hacked it to throw away the addresses so i wouldnt need to store the mapping in the linux memory management <damo22>why does kalloc not have a way to store the size of the request? <damo22>so you wouldnt need to know the size on free <damo22>youpi: do you think the vremap way is bad? <youpi>almuhs: look inside the pmap_mapwindow_t type <almuhs>in some example, the function are used as this way <almuhs>src_map = pmap_get_mapwindow(INTEL_PTE_R(src)); <damo22>the problem is you need to store the mapping somewhere so you can free it <youpi>well, that or you don't free it <youpi>I mean, if you want to free it, well yes you have to have the pointer <youpi>I don't see how it could magically work otherwise :) <damo22>and you need the size stored so you can free it <damo22>so you need a lookup table like linux has <youpi>ah, I thought you meant the problem of the vremap interface <youpi>yes, sure vremap makes it easier <youpi>if it's never to be freed that's much simpler <damo22>it seems to be allocating new memory, and then making the physical page point there? <almuhs>It continues failing in the same point <youpi>not new memory, new adressing space <youpi>not making the physical page ponite there, but make the virtual address space ponit to the physical page <youpi>which is what is needed, yes <youpi>almuhs: I was talking to dam <youpi>almuhs: you really need to read what you are using <youpi>I told you to look at what that function returns <youpi>pmap_mapwindow_t holds a pt_entry_t and a vm_offset_t <youpi>pt_entry as in "page table entry" <youpi>and vm_offset as "virtual memory offset" <youpi>do don't case pmap_map_window_t* into struct acpi_rsdt* <almuhs>static pmap_mapwindow_t mapwindows[PMAP_NMAPWINDOWS]; <almuhs>this is what the function returns <youpi>it's a potner to a structure that contains the pointer <youpi>and that's not the actual virtual pointer <youpi>it's an address of a structure that contains the pointer <youpi>did you print what it returns? <youpi>really, I'm amazed how people nowadays do not just print what they are doing <youpi>people don't seem to realize that yes, computer science is hard and nobody gets it right the first time <youpi>so you just always have to check that things behave the way you thought <youpi>that being said, see what damo22 said <youpi>that'd be more simple and powerful actually <damo22>almuhs: i have a simpler way that does not involve pmap_get_window, you just allocate a new address space and point the physical page there <almuhs>this is the solution which a friend used to map lapic, is not? <youpi>that being said the address you got looks good <youpi>the eip after that looks completely bogus <damo22>i dont think ffffe000 is a good address <youpi>see the pmap window initialization <youpi>it's really put at the end of the kernel memory <damo22>but its reserved in the e820 map <youpi>almuhs: your memcmp looks wrong <youpi>is .signature really a poniter ? ***Server sets mode: +nt
<youpi>err, you only called pa_to_pte <youpi>all other callers of pmap_get_mapwindow use INTEL_PTE_W or R <youpi>which surely is needed indeed <youpi>otherwise if you don't have an R flag you can't read it <almuhs>then I copy the define of #INTEL_PTE_R <almuhs>#define INTEL_PTE_R(p) (INTEL_PTE_VALID | INTEL_PTE_REF | pa_to_pte(p)) <damo22>that define should be in pmap.h but its not <youpi>at least there was no way for the code to work <youpi>yes, we probably want to move it <almuhs>(excuse me the ugly screenshot, Mach runs so fast to shot as other way) <youpi>almuhs: just to be sure you could print kernel_virtual_end <youpi>I really mean kernel_virtual_end <youpi>ooh right there's alignment questions <almuhs>the kernel virtual end is ffffff <youpi>almuhs: ok so the mapping was right <youpi>it's the page alignment that poses problem <damo22>my function above would handle that <almuhs>really, the fail is now in memcmp <youpi>yes, because of alignment problems <youpi>I didn't realize you had a non-aligned address <youpi>so pa_to_pte of course drops some bits of the address <almuhs>I put a phystokv in rsdp start address <youpi>phystokv doesn't hav alignemnt issues <youpi>since it's just adding the segmentation offset <almuhs>with alignment problems, do you refers that the structure doesn't fills in one page? <damo22>the starting address is not on a page boundary <youpi>I'm talking about the rsdt address <youpi>and thus mapping it needs to take care of this <damo22>you can only map to nearest page <youpi>which damo22's function does take care of <youpi>almuhs: the problem is not that it doesn't fit (actually it does) but that the start is not aligned on a page start <youpi>really, read the macros your are using <youpi>see that it drops the rightmost bits <youpi>since it drops part of the address <almuhs>then, do I copy the damo22 function and try It with this? <damo22>it returns a new pointer to a mapped address <almuhs>yes, but I don't know what pass as parameters <almuhs>what must I put in the parameters? <damo22>physical address and size of mapping <damo22>you get back a mapped pointer that should just work <almuhs>../i386/i386at/acpi_parse_apic.c:60:27: error: ‘kernel_map’ undeclared (first use in this function) <youpi>almuhs: you really need to learn to use grep <damo22>when you see errors like that, first "git grep kernel_map" <damo22>put an infinite loop in gnumach after your prints so it doesnt try to boot <almuhs>is this your prototype? pmap_hack (unsigned long offset, unsigned long size) <damo22>not sure if you can assign a struct direct to an address <almuhs>oh, really, I missed the casting <damo22>you kind of cheated, by implicitly casting the memory address to a struct, that doesnt always work depending on padding and bitfield order sometimes <almuhs>printf tell me that rsdt address is 0 <youpi>it's not a struct, it's a poniter to struct <almuhs>this struct doesn't has any bitfield <youpi>almuhs: I mean print inside pmap_hack <damo22>yes its a pointer to a struct but almuhs assigns the pointer and then dereferences the struct members straight out of the memory <youpi>(and if you get lazy to add a print just because it's long to reboot with the rebuilt kernel, work on making rebuild+reboot faster, that will save time in the long run) <youpi>rsdt = pmap_hack (rsdt_phys, sizeof(struct acpi_rsdt)); <youpi> printf("found rsdt in address %x\n", rsdt); <youpi>that will print the pointer, won't it? <damo22>almuhs: check the compiler warnings <damo22>i just wrote that function without testing it <almuhs>compiler warnings doesn't shows any advice about It <almuhs>but I'm exhausted, and I work very slow now <damo22>seems like youre getting null back from kmem_alloc_wired? <youpi>vm_mem_boostrap is called from setup_main only <youpi>possibly vm_map_find_entry can't work earlier than that <damo22>youre calling acpi_setup too early <youpi>really, I don't see why you try to call it that early <youpi>you'll only bump into troubles :) <almuhs>I want to call before start the system <almuhs>because damo22 told that It's necessary to configure IOAPIC even before harddisk drivers <youpi>then you only need to call it before thread_create(kernel_task, &startup_thread); <youpi>since that's where you have all the drivers <almuhs>really, I asked about this a few hours ago <damo22>you probably want to call it just after linux_init <damo22>thats where i put mine and it worked well <damo22>in between linux_init and probe_io <damo22>(10:19:29) damo22: you probably want to call it just after linux_init <damo22>then you can inspect memory in qemu while its stuck in loop <almuhs>continues crashing, but now the fail can be in apic table <almuhs>but gnumach find rsdp and rsdt, and the signature check is correct <almuhs>but I continues the work with apic tomorrow <youpi>damo22: I have just pushed a kmem_valloc, which should be used instead of kmem_alloc_wired (which wastes memory) <almuhs>youpi: finally, tonight I get to find correctly the RSDT reference <almuhs>youpi: do you know if is posible to use rsync to synchronize the host with the VM? <almuhs>I want to avoid to use git to this synchronization <almuhs>do I need to configure something in Hurd to get that rsync works? I've installed rsync package and enabled the service, but I don't get to connect with the machine <youpi>you can just use it over ssh <almuhs>I usually connect to It using localhost and port 2222, but this doesn't works with rsync <youpi>use .ssh/config to get the port automatically set up <almuhs>the apic checksum is successfull, but the code seems fails after <almuhs>there aren't kernel panic, so the problem must be in a "return -1" <almuhs>now the code seems to read APIC without errors. But the lapic and ioapic values are not correct <almuhs>all lapic and ioapic have apic_id=0 
