OSDev.org

I've been working my way through getting different address spaces working, but I've come to a point where I want to copy one physical frame to another. I am able to get the physical addresses, so now I've tried to write an assembly function that just turns off paging, copies the data, and turns it back on - but I'm running into a problem. All my labels are offset by 3GB (0xC0000000, accessible as $VIRTUAL_BASE), which I've been working around by just subtracting that value, but I've now found that i686-elf-as doesn't allow conditional jumps to addresses in registers (ex. jmp *%edx works, jz *%edx does not). Also, it doesn't allow looping to addresses in registers with the loop command, so I'm not really sure what else to do.

I tried to make a specific section that would be linked to the lower half, but only after the multiboot header, which I wasn't able to get working - so the only option I saw left was rep movsb, but I still don't think that's working properly as the function never returns to the C from which it was called, and I think just ends up running garbage somewhere in lower memory (it never gets to re-enabling paging). I believe the best option here would be to just link to the lower half, but since I couldn't get that to work, I'm not sure what to do. Does anyone know how to make one specific section link normally without the virtual memory offset (and force it to come after the mulriboot header), or have any other way to copy one section of memory to another?

Here is what I've made so far:


And the linkerfile, since we're dealing with virtual memory:

Don't turn off paging. Update your page tables to map both regions of memory, if they're not both already mapped. Copy your data. Update your page tables again to unmap any memory you no longer want to have mapped.

Do you need to copy anything in the first place? Paging allows you to map the data at your choice of virtual address.

That's because those instructions don't exist. What's wrong with simply "jmp lower_half_cpp-$VIRTUAL_BASE"?

As for why it crashes, it's because you turned off paging while EIP still points to a high address. Instead of doing this dance every time you want to copy a page, you should probably just map the new page somewhere.

I guess that makes sense too! I had thought it would be easier to just write a snippet of assembly like any other non-paged program would, but just setting up a couple of reserved frames for this purpose could work too.



I had thought cloning address spaces requires copying any non-kernel pages? All the kernel entries I just map to their original places, but I copy everything else to make sure two processes don't collide in memory. Is this not what you're supposed to do?


I was just using that as an example - a better one might be:

Where I'd tried doing as I had been, since the physical address was in edx:

Which, apparently, doesn't exist. Not exactly sure if jnz or any other conditional jump works with the syntax you showed - not at the same computer right now but I'll check later. First I'll try just using paging to map those addresses elsewhere.


So I guess this whole bit was a tad useless, then - I wonder why the instruction set lets that syntax work, but only for plain jmp commands... who knows. Thanks for all the help, I'll go give this a shot when I get back home!

Only if those pages need to contain different data.


That's one way to do it.

Another way is to make the pages read-only and copy them when the new process causes a #PF trying to write to them (copy-on-write). Make sure you set CR0.WP appropriately for your implementation. On Unix-like OSes, where calls to fork() are usually followed by calls to exec(), this is a big optimization.


Only Intel could tell you that. I suggest you refer to the Intel (or AMD) manuals if you want to know which instructions support which address modes.

That did it, it can now copy data from physical frames! Although I was noticing it was too slow for actual use, that sounds like a really good way to tell if they need to access the data there, I'll implement that once I get kernel/non-kernel program interaction working properly, thanks for showing me that! And I'd been using an online reference that bunched them together (the manual takes ages to load on my computer), so it appears the actual manual serves as a better reference, so I'll go there from now on. Anyways, thank you so much for the help!

Direct near jump instructions are relative, so there is nothing to add or subtract in this case. I highly suggest learning the basic IA-32 instruction set before starting on an operating system instead of guessing. I think the individual volumes of the Intel programmer's manual are available as separate files, so you don't have to load the entire thing.