Consider the following code snippet.
if (fork() == 0)
{
a = a + 5;
printf("%d, %d \n", a, &a);
}
else
{
a = a - 5;
printf ("%d, %d \n", a,& a);
}
AFAIK, when fork() is made, the virtual address space of parent is copied to the child and both child & parent share the same physical pages until one of them tries to modify. The moment one of the child & parent modifies a variable, the physical page of parent is copied to another page for child and the physical pages remain private.
So, here value of 'a' is different in child & parent. But when it comes for the addresses of 'a' in child & parent, the output is same. I am not able to figure out why the address remains same even if the physical pages are diffrent.
The address of a is not the actual physical address.
It is a virtual address.
The hardware/OS layer maps virtual addresses to physical addresses (invisibly to your application).
So even though the addresses have the same number they do not map to the same physical memory on your ram chip.
PS. When printing the address (ie pointer) using printf() best to use "%p"
The response is almost in your question: the physical page of a is copied (and thus not the same as in the parent process) after modifying a, but the virtual address (what's seen by your program, through &a) does not change.
In fact it would be very awkward to change the virtual address of a when assigning it a new value. Consider what happens if you had previously stored a pointer to a:
int *p = &a;
a = a - 5;
printf("%d", *p)
After the second line p would not point to a anymore, a behaviour that no programmer would expect.
The use of copy-on-write for physical pages is an optimization of the OS that is irrelevant to the behavior of your program: you can consider that the entire address space is copied when you fork.
Related
I'm trying to loop through all pages for a process in xv6.
I've looked at this diagram to understand how it works:
but my code is getting:
unexpected trap 14 from cpu 0 eip 801045ff (cr2=0xdfbb000)
Code:
pde_t * physPgDir = (void *)V2P(p->pgdir);
int c = 0;
for(unsigned int i =0; i<NPDENTRIES;i++){
pde_t * pde = &physPgDir[i];
if(*pde & PTE_P){//page directory valid entry
int pde_ppn = (int)((PTE_ADDR(*pde)) >> PTXSHIFT);
pte_t * physPgtab = (void *)(PTE_ADDR(*pde));//grab 20 MSB for inner page table phys pointer;
// go through inner page table
for(unsigned int j =0;j<NPDENTRIES;j++){
pte_t * pte = &physPgtab[j];
if(*pte & PTE_P){//valid entry
c++;
unsigned int pte_ppn = (PTE_ADDR(*pte)) >> PTXSHIFT;//grab 20 MSB for inner page table phys pointer;
//do thing
}
}
}
}
This is in some custom function in proc.c that gets called elsewhere. p is a process pointer.
As far as I understand, cr3 contains the physical address of the current process. However in my case I need to get the page table for a given process pointer. The xv6 code seems to load V2P(p->pgdir) in cr3. That is why I tried to get V2P(p->pgdir). However,the trap happens before pde is dereferenced. Which means there is a problem there. Am I not supposed to use the physical address?
Edit: As Brendan answered, the virtual address p->pgdir is what should be dereferenced. Additionally, the PPN from the Page directory should also be converted via P2V to properly dereference into the page table.
If someone else also gets confused about this aspect of xv6 in the future, I hope that helps.
When dealing with paging the golden rule is "never store physical addresses in any kind of pointer". The reasons are:
a) They aren't virtual addresses and can't be dereferenced, so it's better to make bugs obvious by ensuring you get compile time errors if you try to use a physical address as a pointer.
b) In some cases physical addresses are a different size to virtual addresses (e.g. "PAE paging" in 80x86 where virtual addresses are still 32-bit but physical addresses are potentially up to 52 bits); and it's better (for portability - e.g. so that PAE support can be added to XV6 easier at some point).
With this in mind your first line of code is an obvious bug (it breaks the "golden rule"). It should either be pde_t physPgDir = V2P(p->pgdir); or pde_t * pgDir = p->pgdir;. I'll let you figure out which (as I suspect it's homework, and I'm confident that by adhering to the "golden rule" you'll solve your own problem).
This question refers to an architecture using segmentation with paging. In this architecture, the 32-bit virtual address is divided into fields as follows:
4 bit segment number | 12 bit page number |
16 bit offset
Find the physical address corresponding to each of the following virtual addresses (answer "bad virtual address" if the virtual address is invalid).
1.00000000
2.20022002
3.10015555
Please help me with this, i dont know how to create page table and segment table for this mapping !!!
You are a little shy on details, so lets fill in a few:
Each segment has a 4096 (=2^12) entry translation table associated with it; otherwise it would not be interesting.
Each entry will contain a physical base address.
The extra offset will be added to this base address to find the final one.
So, in this hypothetical MMU, we could have a function like:
paddr_t translate(uint32_t vaddr) {
return segment[vaddr>>28].page[(vaddr>>16)&0xfff] + (vaddr & 0xffff);
}
A real (useful) mmu would have a bit more like:
paddr_t translate(uint32_t vaddr) {
seg_t *seg;
page_t *page;
if ((seg = segment[vaddr>>28]) && (page = seg->pagetab[(vaddr>>16)&0xfff])) {
return page->base + (vaddr & 0xffff);
} else {
raise(SEGV);
}
}
this is showing the sparseness of both segments and page mappings. It would likely have some permissions, as well, but this should help get you to the next obstacle.
if mmap() was used to read a file, how can I find the number of data mapped by mmap().
float *map = (float *)mmap(NULL, FILESIZE, PROT_READ, MAP_SHARED, fd, 0);
The mmap system call does not read data. It just maps the data in your virtual address space (by indirectly configuring your MMU), and that virtual address space is changed by a successful mmap. Later, your program will read that data (or not). In your example, your program might later read map[356] if mmap has succeeded (and you should test against its failure).
Read carefully the documentation of mmap(2). The second argument (in your code, FILESIZE) defines the size of the mapping (in bytes). You might check that it is a multiple of sizeof(float) and divide it by sizeof(float) to get the number of elements in map that are meaningful and obtained from the file. The size of the mapping is rounded up to a multiple of pages. The man page of mmap(2) says:
A file is mapped in multiples of the page size. For a file that is
not a multiple of the page size, the remaining memory is zeroed when
mapped, and writes to that region are not written out to the file.
Data is mapped in pages. A page is usually 4096 bytes. Read more about paging.
The page size is returned by getpagesize(2) or by sysconf(3) with _SC_PAGESIZE (which usually gives 4096).
Consider reading some book like Operating Systems: Three Easy Pieces (freely downloadable) to understand how virtual memory works and what is a memory mapped file.
On Linux, the /proc/ filesystem (see proc(5)) is very useful to understand the virtual address space of some process: try cat /proc/$$/maps in your terminal, and read more to understand its output. For a process of pid 1234, try also cat /proc/1234/maps
From inside your process, you could even read sequentially the /proc/self/maps pseudo-file to understand its virtual address space, like here.
Whenever I try to write a pixel to the LFB of VESA mode, I get a page fault where the page is present and has been read. My paging implementation is from James Molloy's OS series. I've tried identity mapping the LFB as follows:
for (unsigned int i = 0xFD000000; i < 0xFE000000; i += 0x1000) {
page_t* pg = get_page(i, 1, kernel_directory);
alloc_page(pg, 1, 1);
}
These are the prototypes for those functions:
page_t* get_page(uint32_t address, int make, page_directory_t* dir);
void alloc_frame(page_t* page, int is_kernel, int is_writeable);
When paging is disabled, I'm able to write pixels to the LFB without any issues. Am I identity mapping the LFB incorrectly? Is there something else I need to do to identity map it correctly? Any suggestions?
When paging is disabled, your accessing address is the physical address. However, when paging is enabled, your accessing address is virtual, so you should first map the address region you will access to a phsyical address region. This can be implemented by the remap_pfn_range or nopage function, as introduced here.
I'm using a STM32F401VCT6U "discovery" board, and I need to provide a way for the user to write addresses in memory at runtime.
I wrote what can be simplified to the following function:
uint8_t Write(uint32_t address, uint8_t* values, uint8_t count)
{
uint8_t index;
for (index = 0; index < count; ++index) {
if (IS_FLASH_ADDRESS(address+index)) {
/* flash write */
FLASH_Unlock();
if (FLASH_ProgramByte(address+index, values[index]) != FLASH_COMPLETE) {
return FLASH_ERROR;
}
FLASH_Lock();
} else {
/* ram write */
((uint8_t*)address)[index] = values[index]
}
}
return NO_ERROR;
}
In the above, address is the base address, values is a buffer of size at least count which contains the bytes to write to memory and count the number of bytes to write.
Now, my problem is the following: when the above function is called with a base address in flash and count=100, it works normally the first few times, writing the passed values buffer to flash. After those first few calls however, I cannot write just any value anymore: I can only reset bits in the values in flash, eg an attempt to write 0xFF to 0x7F will leave 0x7F in the flash, while writing 0xFE to 0x7F will leave 0x7E, and 0x00 to any value will be successful (but no other value will be writable to the address afterwards).
I can still write normally to other addresses in the flash by changing the base address, but again only a few times (two or three calls with count=100).
This behaviour suggests that the maximum write count of the flash has been reached, but I cannot imagine it can be so fast. I'd expect at the very least 10,000 writes before exhaustion.
So what am I doing wrong?
You have missunderstood how flash works - it is not for example as straight forward as writing EEPROM. The behaviour you are discribing is normal for flash.
To repeatidly write the same address of flash the whole sector must be first erased using FLASH_EraseSector. Generally any data that needs to preserved during this erase needs to be either buffered in RAM or in another flash sector.
If you are repeatidly writing a small block of data and are worried about flash burnout do to many erase write cycles you would want to write an interface to the flash where each write you move your data along the flash sector to unwriten flash, keeping track of its current offset from the start of sector. Only then when you run out of bytes in the sector would you need to erase and start again at start of sector.
ST's "right way" is detailed in AN3969: EEPROM emulation in STM32F40x/STM32F41x microcontrollers
This is more or less the process:
Reserve two Flash pages
Write the latest data to the next available location along with its 'EEPROM address'
When you run out of room on the first page, write all of the latest values to the second page and erase the first
Begin writing values where you left off on page 2
When you run out of room on page 2, repeat on page 1
This is insane, but I didn't come up with it.
I have a working and tested solution, but it is rather different from #Ricibob's answer, so I decided to make this an answer.
Since my user can write anywhere in select flash sector, my application cannot handle the responsability of erasing the sector when needed while buffering to RAM only the data that need to be preserved.
As a result, I transferred to my user the responsability of erasing the sector when a write to it doesn't work (this way, the user remains free to use another address in the sector to avoid too many write-erase cycles).
Solution
Basically, I expose a write(uint32_t startAddress, uint8_t count, uint8_t* values) function that has a WRITE_SUCCESSFUL return code and a CANNOT_WRITE_FLASH in case of failure.
I also provide my user with a getSector(uint32_t address) function that returns the id, start address and end address of the sector corresponding to the address passed as a parameter. This way, the user knows what range of address is affected by the erase operation.
Lastly, I expose an eraseSector(uint8_t sectorID) function that erase the flash sector whose id has been passed as a parameter.
Erase Policy
The policy for a failed write is different from #Ricibob's suggestion of "erase if the value in flash is different of FF", as it is documented in the Flash programming manual that a write will succeed as long as it is only bitreset (which matches the behavior I observed in the question):
Note: Successive write operations are possible without the need of an erase operation when
changing bits from ‘1’ to ‘0’.
Writing ‘1’ requires a Flash memory erase operation.
If an erase and a program operation are requested simultaneously, the erase operation is
performed first.
So I use the macro CAN_WRITE(a,b), where a is the original value in flash and b the desired value. The macro is defined as:
!(~a & b)
which works because:
the logical not (!) will transform 0 to true and everything else to false, so ~a & b must equal 0 for the macro to be true;
any bit at 1 in a is at 0 in ~a, so it will be 0 whatever its value in b is (you can transform a 1 in 1 or 0);
if a bit is 0 in a, then it is 1 in ~a, if b equals 1 then ~a & b != 0 and we cannot write, if bequals 0 it's OK (you can transform a 0 to 0 only, not to 1).
List of flash sector in STM32F4
Lastly and for future reference (as it is not that easy to find), the list of sectors of flash in STM32 can be found on page 7 of the Flash programming manual.