Bitmap or stack based memory manager

[Tim]

For completeness, here's a list of the virtual mappings in the Mobius kernel:

[tt]Kernel image 0xC0000000-0xD0000000
[spare] 0xD0000000-0xDFC00000
Kernel stacks 0xDFC00000-0xE0000000
Kernel heap 0xE0000000-0xE8000000
Kernel VmmAlloc space 0xE8000000-0xF0000000
Physical memory 0xF0000000-0xF8000000
Temporary mappings 0xF8000000-0x100000000[/tt]

[Whatever5k]

This virtual addresses were chosen, not determined. I mean you could have chosen other addresses, right?

[Tim]

Yes, that's right.

[Whatever5k]

Why don`t you use the virtual addresses below 0xC0000000?
I will have to determine the virtual addresses for kernel image, kernel stack, etc., too. So why don`t map virtual address 0x0 to physical 0x10000000 (where Grub loads my kernel)? The problem is that I will have to map the space beyond the kernel - have to take care that there are no collisions... .
So what do you think? Should I do it like this? For the moment, I only have the first 4 mb mapped, and this is done 1:1...

regards,
A.Blessing

[pskyboy]

Because Below 0xC0000000 is for applications to use as the kernel will be mapped to the top of every 4Gb application VM space.

Peter

[Whatever5k]

Alright, although I don't have any applications to run yet, I could map it that way, right?
I'd do it like this:

Code: Select all

void mm_setup()
{
...
MemMap(0xC0000000, kernel_image, 0x100000000); 
...
}

0x100000000 stands for the end of memory (actually the end of the mapping - trying to access memory beyond this will generate a page fault).
Could I do this like this?

[Tim]

Yes, but you'd be better off implementing MemMap like this:

Code: Select all

void MemMap(void *virtual, addr_t physical, unsigned num_pages);

The way you've written it, you'll have to use 64-bit addresses (0x100000000 is just over 4GB) and there's no need. Better to express it as a starting address and the number of pages to map.

[Whatever5k]

Ok, I've come to a decision. I won't be using 0xC0000000 as the start address of kernel image. I don't have any applications to run yet so that would be unnecessary. I will map the first 4MB of memory, 1:1. Now I only have to figure out which (virtual) address stands for the (beginning) of the heap. Would something like this work?

Code: Select all

init_mm(void)
{
addr_t heap;
...
/* map from beginning to end of bss */
MemMap(0, 0, ebbs / PAGE_SIZE);
MemMap((addr_t) heap, ebss, (end - ebss) / PAGE_SIZE);
...
}

[Tim]

What you've written in your code doesn't seem to match what you've written yourself.

Code: Select all

MemMap(0, 0, ebbs / PAGE_SIZE);

Map a region of ebbs bytes from virtual address zero to physical address zero. Is ebbs a typo of ebss? If so, will identity map all memory up to the end of your kernel, which may or may not be 4MB.

Code: Select all

MemMap((addr_t) heap, ebss, (end - ebss) / PAGE_SIZE);

Map a region of end - ebss bytes from virtual address 'heap' to physical address 'ebss. How is end different to ebss? Is end the end of the heap? Usually end refers to the end of the kernel image, which is the same as ebss.

I think I understand what you're doing now. You're having the kernel use identical virtual and physical addresses, and putting the heap at the end of the kernel. The heap also uses identical virtual and physical addresses.

So far so good (I think); there's nothing stopping you treating virtual addresses and physical addresses the same way like this. Once you start running user-mode code, you'll have to put its virtual addresses in the top half of the address space, right? So the kernel occupies the bottom, along with some of the physical RAM, and the user-mode memory occupies the top?

One problem with this approach is that you won't be able to use V86 mode if you decide to. V86 mode is hard-wired to use the bottom 1MB of the address space, which is currently used by your kernel, and is hard-wired to run in ring 3. You'll either have to unprotect your kernel memory (thereby allowing all other ring 3 code to access it) or move it (thereby leaving the bottom 1MB free).

Now I only have to figure out which (virtual) address stands for the (beginning) of the heap.

You don't have to figure it out, you just pick an address out of the air, and as long as you don't start using that region for something else, it will work. Remember that this is virtual memory, and you've always got 4GB to do what you like with (except that bottom 1MB V86 thing).

[Curufir]

Don't forget the 16mb limit on DMA operations while you're laying out the address space.

[Tim]

...the 16MB limit on physical addresses. Although you can only use ISA DMA with physical addresses below 16MB (PCI DMA is unaffected), you can map those physical addresses anywhere you want within the virtual address space. Remember that nothing outside of the processor knows about virtual addresses, only physical.

[DarylD]

Incidentally, a question to those who have done it.

I am coming to the stage where I will need to be able to read files from disk.

I don't have either a working floppy driver or IDE driver, although I do have some floppy code that is quite far along.

What I wan't to ask is this: How difficult is it going to be for me to get IDE disk access going, should I use V86 mode instead for now, if so what sort of performance impact should I expect?

Thanks.

[Whatever5k]

Ok, Tim, what do you think of this approach?

Code: Select all

extern addr_t kernel_end, ebss;

void mem_init(void)
{
addr_t heap;
...
MemMap(0, 1048576, 1024); /* map first 4 MB */
heap = (ebss - 1048576);
....
}

How about this approach? So I leave the first 1 MB free for V86 (although I won't use it I think), and I map the first 4 MB. The heap is ebss - 1 MB.
What do you think?

[Tim]

DarylD: once you've got detection sorted, accessing IDE drives is probably easier than floppy drives, since you don't need to handle the motor or DMA. But better to start a thread if you want to discuss it more.

abless: so here you're mapping the bottom 4MB of physical memory at virtual addresses 1MB-5MB, right? That's OK. But why are you having your heap start 1MB below the end of your kernel? Aren't you afraid that the heap and kernel will overlap at some point? Isn't it better to have it starting at the end of the kernel?

[Whatever5k]

so here you're mapping the bottom 4MB of physical memory at virtual addresses 1MB-5MB, right?

Exactly...

But why are you having your heap start 1MB below the end of your kernel?

Well, I do 1:1 mapping, so this would be ok:
heap = ebss;
But virtual address 0 is physical address 0x100000, so I subtrahact this. Consider, ebss is 2 MB. Now I map virtual 0 to physical 1 MB. Then virtual 1 MB would be physical 2 MB, that is the heap. Now to get this, I would do
2MB - 1MB = 1 MB, that is:
ebss - 1MB = virtual heap address;

Do you understand what I mean?
best regards and thanks for your help,
A. Blessing