Page 1 of 1

vmmngr problem

Posted: Mon Dec 07, 2009 2:17 pm
by djsilence
Hi. I have some problem with vmmngr. See, it has vmmngr_alloc_page(). This function returns address of allocated memory. But actually it doesn't work properly. First of all: if you try to allocate page it returns addresses below first 4MB (because pmmngr_alloc_block() returns such). And doing this: (*(uint32_t*)0x1000) = 0x123456; givess no page fault if my page is allocated and pt_entry = 0x18FF (address 0x1000 + attributes.); But even if I do not alloc page I can write to that address. The reason of it is that we allocated first 4MB in our bootloader. But if I try to allocate page at address 0x400000 I do the next:

Code: Select all

pt_entry e;
void * p = (void *)0x400000;

pt_entry_set_frame (&e, (physical_addr)p);
pt_entry_add_attrib (&e, I86_PTE_PRESENT);
and then I try to do the next:

Code: Select all

(*(uint32_t*)0x400000) = 0x123456;
What I'ge got? General Protection Fault. I see that GPF is like a page fault, because if I try to write to non-allocated address I get no PF - I get GPF.

So, next I tried to do the next:

Code: Select all

extern pdirectory * _cur_directory;

(*(uint32_t*)(_cur_directory + 4*0x400000/0x1000)) = e; // this I do if I know exactly the number of page.
vmmngr_switch_directory(_cur_directory);
What I've got? GPF again.

But If I do not modify _cur_directory and do just

Code: Select all

vmmngr_switch_directory(_cur_directory);
I got no GPF.

So, what is wrong in my tryings or maybe in vmmngr?
Daniel.

Re: vmmngr problem

Posted: Mon Dec 07, 2009 10:06 pm
by Andyhhp
if you are getting GPFs, then you probably have a fault with your PF handler. If all is working well (which your posted code would suggest), then GPFs shouldnt happen.

I suggest you check your PF handler very carefully.

~Andrew

Re: vmmngr problem

Posted: Tue Dec 08, 2009 12:42 am
by Neutron

Code: Select all

pt_entry e;
void * p = (void *)0x400000;

pt_entry_set_frame (&e, (physical_addr)p);
pt_entry_add_attrib (&e, I86_PTE_PRESENT);

Code: Select all

(*(uint32_t*)0x400000) = 0x123456;
This should produce faults if the pt_entry is not yet in the current page table and you didn't set I86_PTE_WRITABLE-attribute (without it any attempt to write to mapped address will generate a general protection fault).

Re: vmmngr problem

Posted: Tue Dec 08, 2009 9:29 pm
by djsilence
I do not know how can it be, but when i do:

if (pt_entry_is_writable(e)) printf("writable");

I get "writable". But actually I did not set it, and pt_entry_set_frame does not, and pt_entry_add_attrib() doesn't.

And if I set it by doing pt_entry_add_attrib(&e, I86_PTE_WRITABLE) it to writable myself - anyway I get GPF.

Daniel.

Re: vmmngr problem

Posted: Tue Dec 08, 2009 9:35 pm
by djsilence
Just of an interest - what is virtual address? See, 0x400000 - it is physicall adress, but how can I get virtual address of physical memory area??

Daniel.

Re: vmmngr problem

Posted: Wed Dec 09, 2009 1:56 am
by Mike
Hello,

The VMM in the series is a little complicated in its interface and can be made easier to work with. It is planned for an update.

If you only have a physical address, it is not possible to know what virtual address maps to it. The reason being that of shared addresses. That is, it is entirely possible to map more then one virtual address to the same physical address so both virtual addresses refer to the same location.

A virtual address, on x86, is just an address that follows a specific bit format that describes the page directory entry, page table entry, and the offset in it. The VMM chapter contains the bit format along with how it works.

Re: vmmngr problem

Posted: Wed Dec 09, 2009 10:24 am
by djsilence
Thanks, Mike.