OSDev.org

Hello,

When spawning a user process with a new page directory I copy the relevant kernel PTE's/PDE's to the user process page directory so I won't have to switch a page directory when doing system calls, and thus the page directory when running in CPL0 (in a system call) can access the kernel data.

However, what happens when the kernel page directory / page tables change? for example a kernel malloc that maps additional kernel pages which the system call can access from the user process?

What I'm doing now is going over all the processes and modify the relevant page directory part to match the new kernel page directory but it's pretty exahustive (every page map needs to do this update for user processes) and there must be a better way, how are you guys handling it? any ideas?

Another small weird thing, I'm trying to set the keyboard's repeat/type rate to maximum repeat minimum type delay (fastest writing) but this just doesn't seem to work under Virtual PC.
AFAIK you send 0xF3 to port 0x60, get the ACK, and then send the typematic byte to port 0x60 (in my case 0x0 for least delay) but this just doesn't make a difference.
I've seen the same code in other places and I guess it works there. Any thoughts? (experience with Virtual PC?)

Thanks,
Daniel.

i was asking myself the same questions about the paging part of it...so any replies is also appreciated for me

About the keyboard...don't forget that you are running a virtual PC and that the actual typerate is affected firstmost by the operating system that you are running IE windows or linux....so you could potentialy make it slower but not faster.

About the keyboard rate problem - the emulation (virtual pc / vmware / bochs) maintains its own state of the entire "virtual computer" therefor it emulates as much as it supports and should support such trival thing.
(The only problem here might be if the HOST system [ie WINXP] has the keyboard driver set to a slower rate in which case there isn't any way for the emulation to get keyboard input faster than the host since it uses the host to get the input in the first place).

After some extensive tests I have found out that keyboard type rate functions are NOT supported under Virtual PC (they just doesn't work on real OS's within Virtual PC as well.)

So please disregard that question.

Thanks
Daniel.

Hi,

Trashey wrote:However, what happens when the kernel page directory / page tables change? for example a kernel malloc that maps additional kernel pages which the system call can access from the user process?

What I'm doing now is going over all the processes and modify the relevant page directory part to match the new kernel page directory but it's pretty exahustive (every page map needs to do this update for user processes) and there must be a better way, how are you guys handling it? any ideas?

If you change the kernel's page tables (or page directory entries) you need to make the same change in every page directory/address space. The fastest way to do this is to map every physical page that is used for a page directory into the kernel's part of the address space so you can update all page directories without changing CR3.

An alternative would be to pre-allocate all page tables that could be used in the kernel's part of the address space/s. This can be a bad idea - if the kernel can use up to 1 GB on large computers, then you could end up pre-allocating 256 page tables (or 1 MB) on smaller computers that may never be entirely needed.

If you're using PAE, then none of this is necessary as the same page directory (or directories?) are mapped into all page directory pointer tables (or address spaces).

Trashey wrote:Another small weird thing, I'm trying to set the keyboard's repeat/type rate to maximum repeat minimum type delay (fastest writing) but this just doesn't seem to work under Virtual PC.

Does it work on a real computer?

The problem with emulators is that they emulate - the keyboard should do what the host OS tells it to do, rather than what the emulator (or guest OS) tells it to do. Consider a computer running 2 versions of the emulator, where both guest OS's set opposite keyboard settings at the same time.


Cheers,

Brendan

Nowadays I preallocate kernel page tables at the virtual memory init, so that copying the PDEs will take care of this (as we only map more pages in the PTEs, and never new page tables).

But I used to do it in a different way: I had a lookup table for "shadow entries" for the kernel-space PDEs; just a regular array with the same information as a PDE would have. Since the table was allocated before any copies where made (in fact it was statically allocated, but that doesn't really matter), any copies could access the table. When mapping new page tables in kernel space, you'd write the same entry in the shadow-map.

I then had a page-fault handler, which would notice that a kernel-address PDE had 'not present' entry, and would look into the shadow-map to see if there was an entry there. If so, it'd copy the entry into the current page directory, and try again.

I could do this again (if I started caring about memory usage a bit more), but at some point I rewrote most of the virtual memory management, and thought that it wasn't worth it: for 512MB maximum kernel heap you need 512k page-tables preallocated, and if you are going to have 512MB kernel heap, then you probably have enough memory not to care about those 512k.