 All right, let's let's get started so Before we again before we talk about today's content Let's do quick do a quick recap of what we talked about last time. So we basically go over the virtual memory bootstrap process so Here is what the physical memory looks like in different stages in the boot up process So it at the very beginning before even kernel gets running This exception handler is loaded into memory occupy some physical physical memory and then kernel is loaded right after that after that so after after Rambo strap we kind of know how much memory do we have and What's the end of the kernel? Which is the start of the available physical address then at this point? and You can call RAM still memory to keep allocating some memory before you have a functional call map and When you reach Vm bootstrap, this is what the physical memory looks like part of the physical memories has been already occupied and you know the first available physical address by looking at the first physical address variable in RAM docy and Inside RAM boot Vm bootstrap. You are supposed to initialize the com app at this at this and After Vm bootstrap or came out requests should go to allocate K pages Which should call your code to allocated pages so before Vm boot get Vm boot get a bootstrap Allocated K pages can just a call a Rem still memory. It's okay. And after Vm bootstrap You should consult your com app to do the physical page allocation instead of just to call RAM still memory right, so this is the view of the physical memory during the bootstrap process and it can You can sort of imagine what it what is like after the system is running for a while So this part is we'll be still there kernel will be still there stolen There is no way to free the stolen pages So com app will be still there. So inside these are blank free memory chunk some of the pages will be occupied some of them will be available and That status is reflected in your com app data structure So during the whole lifetime of the kernel this part is kind of fix Even including the com app because the com app size doesn't change Right, so what it was changing is the status of the pages after this region or the available regions One after Vm gets bootstrapped so this is the view of the physical memory and We also looked in detail what the com app looks like so basically com app is the array of entries right each entry corresponding to one physical page and That entry contains some many information about that page Whether the page is available. What's the page status? What's the page's owner and so on right, so You can figure out how many com app entries you need by Calculating how many physical pages do you have in total say you have 1,000 physical pages Then the length of the com app will be 1000 Then inside each com app entry you need to decide what information you want to keep For the comma for each page, right? We already mentioned that you want to keep whether the page is available or not and You want also want to know When you call allocated key pages, how many pages exactly was allocated? So later on when you call free key pages, you can free exactly that many physical pages and You also need the only information For So later on when you do swapping you can notify the owner. We will talk about that In next recitation So for now you can keep your com app Minimal I mean you can only keep the page page and chunk size You didn't you don't need to worry about the owner for now And later on when you do need to record the owner information you can just add more fields to the com app entry I assume it's a C structure. So it's very easy to add fields into it so this is the what's the com app looks like and At the end of last recitation We also look at how MIPS translate different virtual addresses Depending on which region that virtual address falls into, right? So if it's a user address, which is defined by below or X at a medium the hardware will consult the TLB to figure out the correct physical address and it's the kernel's responsibility to manage the TLB to fill in correct values into the TLB so the hardware can do the correct translations If the virtual address is in that kernel segment zero region then the hardware will know that okay This address is a kernel address, right? I will not use the TLB Instead I will do the direct translation by Substructing that virtual address by OX at a medium which is effectively Equivalent to just ignore the most significant bit of the virtual address and Use that to as the physical dress and you can see that since that region that virtual address region is the size of it is 512 megabytes fixed No matter how much physical memory you have that's more virtual memory region is the size of it is fixed So you can imagine that Some portion of the virtual addresses cannot be mapped to Physical address not all of them are being mapped to physical address for example, you only have four megabytes of physical memory. That's what you have all you have and You accesses some virtual memory that above these four megabytes region say somewhere here at the top of the region Then the hardware don't really know how to handle it You will get get some buzz error and something like that because you don't have enough physical memory And similarly for kernel segment one we have the similar mapping just that's the hardware will adopt a different catching policy So in this assignment, you don't need to care about the kernel segment one You don't need to worry about that and similarly for kernel segment two is not used in this assignment You don't you don't Need to use that either So what you guys will be doing most in this assignment is the view virtual dresses in user segment which is belong to user program and also in current segment, which is the kernel's own memory and If you kind of know this figure You you will have some some idea of the questions like Why the kernel physical kernel virtual pages has to be continuous Right, that's the one requirement in allocated key pages. You cannot just give in an Abiturated pages that and pages has to be continuous Both virtually and physically that's because of the we don't have that tib mapping capability in kernel for kernel addresses and you also know that Why when you find some victim to swap out when you don't have physical memories? You cannot choose the kernel pages because we don't have that TLB in the middle to help us capture Whether that page is swapped out or not. So once you advocate the physical page is dancing memory It will never being swapped out So that's basically what we talked about last time any questions before we go on Okay So today we're gonna talk about the User address space so last time we basically covered the physical management management the com app stuff this time We'll talk about the user address space including How to design the page table? What's the user address space looks like and how to handle the tlb and virtual memory fault? So first page table as you already know page table is a mapping between the physical between the virtual and Physical addresses right the functionality is over the page table is quite simple given a virtual dress find me physical address associated with that virtual address right so You win you will realize that in earlier in some Excite Assignments you have some other similar data structures like file table Which is a mapping between the file descriptor and the file handle You have a mapping and also process table is a mapping between the process ID Which is integer to the process structure so you have all kinds of these mappings and for For a map you would easily imagine what's the requirement or what's the interface interface of the map? so The functionality of the page table is nothing but what a normal map should provide So giving a virtual dress and a given operation you get this to information in the VN for the handler So say user want to access this virtual dress either to write it or read From it so the page level should be able to tell me that first of all whether this operation is valid So say user want to write to virtual memory can the user actually write to it If the page is read only then you cannot really write to it, right? So the page table should tell me that information and the second information which is a more Important information is that if the operation is valid Which is most of the cases then give getting me the physical address associated with that Virtual dress so this is the requirement of the page table you want to keep this in mind when you design your actual page table structures and How many of you have already have some page table structure written? How many of you have done with the cam 1 and cam 2 test? That's good half of them Yeah, other others what may want to catch up because you are really supposed to get that part down already and so we'll talk about a several design alternatives of the page table and first the first one which is the simplest one will be the link list and So a natural way to implement a map is that internally you have a list of all the map entries, right? So every time you are being asked that giving a virtual dress. Tell me some information You just a traverse that list or array and then you are written the corresponding list. It's a list not an array because Different users may have different memory foot footprint Right some of some user programs may occupy a lot of memory in which case you need a lot of entries While others like being true being false only occupy one or two pages. So the size is variable That's why you cannot use a fix size array to to handle the to use it in the page table and so if you use Adopt this design option, then you it's quite Intuitive that each link list and node is an entry in the page table Then you link all those node up. This is who this will be your page table, right? And So you store some information inside the list of note about the mapping Where's the word was the virtual dress was the physical dress and some other information and Whenever you want to carry this list you have to traverse the whole list in the worst case You have to traverse the whole list before you can find a hit Right, so let's first talk about what information you want to store in each list of note Then we move on to what's the operation to do on the page table So first of all because it's the mapping you have a key, which is the virtual dress, right? Note that this virtual dress is not some arbitrary virtual dress It's the virtual pages base address, which is always 4k aligned, right for for a virtual page You always want to use some aligned address as the key to represent that virtual a virtual page All right in this case we are using the base address of the virtual page So this virtual dress could only be the multiples of 4k right 4k 8k 16k and so on so this the virtual dress we have it as the key and Other parts is sort of the value of this entry We have the physical dress which is corresponding to the physical dress of the actual physical page again This physical address is also page aligned right for each page you want to use some aligned address as the page is address Then you may want to store other informations also because for Given virtual dress and operation you want to tell whether or not this operation is valid first of all Before you move on you continue to try to get the physical dress, right? So here you want to stay store some permission information Right is this page readable is this page writeable is Executable and so on and also you may also want to store some state information For example, the the this virtual page could be swapped out You want to record that information somewhere So when you have a page fault on that virtual page, you'll know where to find the The virtual page on the disk Right, so this is the sort of information you want to store in your page type entry And finally, of course, this is because this is the link list and we have appointed to the next entry of the Next entry of the page table So this is the What one note of the page table looks like any questions of this? I see several people use this kind of design. I mean, there's nothing wrong with it. It's just It's simple and you may be familiar with the link list in the destructor course so it's okay to use it and Of course, they are pros and cons of this approach. What's the advantage of this approach? What's that? Yeah, so you can imagine that most of the user user virtual address will be sparse in the sense that In the in the in all the two gigabyte virtual pages Only a small tiny portion of the pages are actually being mapped to physical pages Right. So if we use a link list, you are very flexible on how many pages you need You can allocate as many as page table entries on demand Which is safe some space Right. So the the page table size depend on how large the user program is If the user program is really Lightweight like Bintro and Buford, you end up really you end up using much less page type entries That's what advantage of this approach and Another advantage of course is is simple. It's a you can is something you can understand and digest and The the because the the data advantage of this approach is also obvious It's the wrong time, right efficiency. So every time You want to query some virtual address the worst case scenario You have to traverse up all the link list the complexity will be big o n That's the the price you pay but for this are some and Efficiency or performance is really not the concern here So it's okay to use this kind of link list and in terms of a special space efficiency actually Suppose that most of the virtual pages will be used then was When then what's the efficiency of this in terms of space? So how large is one table entry where a page type of entry? So first of all you have a pointer which is fixed four binds You have virtual dress physical dress again four bytes each you have 12 bytes already Then you have some other information like permissions that and if you do a really good job You can compress it to another four bytes. So it's 16 bytes per entry imagine you have a bunch of this and It is it's more of a vias when you compare to the next design alternative, which is the actual page table So for each entry you need 16 bytes whereas in the letter design Alternative you only need four. So speaking of a fish especially efficiency or It's really a Two-side thing, right? So on one hand you can allocate as You can be very flexible about how many page type of entries you need on the hand You do end up using more memory or using more bytes for each page type of entry So the second design alternative is the classic two-level page table that you learned from the class right because The virtual dress is fixed is 32 bytes and we can split the by the beads in the address into different regions And we use them to index different tables. So for example a possible design could be like this I use the first 10 bit. This is a lowest Significant a bit. This is the high significant bit. I use the the higher 10 bit as the index to first level page table right Because I have 10 bit. How many page type entries do I need to allocate here? 2 to the power of 10, which is 1k 1k entries here, right? So the first of 10 bit you can use the first 10 bit to Identify the entry in the first level page table. Of course, you have some fixed pointer in your address address base structure to identify the base address of the page table, right? Given the best table page table base given the index you can single the 10 bit as index is integer You can find the page the entry in the first level page table Given this entry, this entry are supposed to point to the base of the second level page table Right, so then you can use the middle 10 bit as an index again to index this array to find out the the entry the arrow should point to here It should point to this entry So finally you look at this entry and this entry contains the best physical address Of the page, right? So this is one page and then you can use the last 12 bit as an index into this As offset into this pair physical page to figure out what's the actual byte, right? So as The kernel you only need to worry about the first two step Which is look at the entry in the first level page table and the entry in the second level page table Then you can just then you are pretty much down. You got the best address of the page and you just Fix up the TIP entry and you'll be done with it. You don't need to worry about the third bit offset So this is the classic two level page table design It's sort of complicated as first glance, but it's what's being really used in reality and If you're working on x86 architecture, you will notice that this kind of structure is actually enforced by the hardware So in terms of advantage and these advantages of this approach So you can compare with the linked list approach. The advantage is what? constant lookup time, right? No matter What which kind of virtual dress you want to look up I always spend a constant time Which is one query to carry then I got the physical dress so you always spend a constant time looking up the page table and Of course the deal of disadvantage is that you may don't know really how to do it and It's kind of complicated and also for each page table entry what's the How many bytes you use for each page table entry? No, that's not true. It's 32 bytes You mean one entry? Yeah, I think that's the case so you basically pay four bytes for each page table entry, right? So you initially you may see that for each virtual dress I need to carry two four bytes entries to get it. It may struck you as oh I need eight bytes for each entry But that's not true because these four bytes is shared among all the page type entries in the second level So that the space cost of the first table Entry is actually amortized in the second level which is kind of negligible because you are using four bytes for 1000 entries four divided by 1000 is zero So you basically pay four bytes for each page type of entry, right? And also you don't have to allocate this whole chunk for every entries, right? You can allocate this you can allocate in the second level page table on demand only when you need to access it so any questions on this page table design the the linked list approach the two level page table approach Which one do you like? So the there is only one first level page table that page table contains one thousand entries one thousand twenty four actually right and Initially, that's what are you all that all you need You don't need to allocate any second level page tables at that point and when user program gets running and have page table When you query this first level you find that this is points nothing That's the that's a time you allocate the second page table and second level page table for that entry Right, so you don't have you don't have to allocate the second level page tables at all at first unless you need to So in in in times of page fault when you pay for page fault first You have the photo address, right? And you can get the first 10 bit of the photo address carry this table because this table is always there Get this entry and see if this entry is see the value of this entry points to some other pet table If it's now means that it doesn't point to anything Then you allocate a second level pet table and set up the link so that it points to the sex there then you query the second level and Initialize this pet table entry Right in other cases, so let on say suppose you have another Page fault which has the identical for the 10 bit Then you don't have to allocate another pet a second level page tables. You can just use this one So which one do you want to use? To levels you like challenges It's no there's no right or wrong to use either approach You can choose whichever one you are this one is more classical and is It's more practical in the sense that it's actually being used the previous one No real system will use that but it's okay to use it in these kind of toy expert Assignments, so any questions about the page table design? Okay, good. So let's move on to the user address base so you you at this point you all kind of get familiar with what the user of virtual dress looks like right somewhere in here we have a code segment and Which contains the code of the user program and we have a data segment for the user Which is the static allocated variables and we have a heap which grows upward and at the top of the user address We have a stack which grows downwards so this is what the user address best look like and In the address base structure you kind of know what information you want to keep right for example you want to know What are those regions right where does the region start how large is the region that's the information you want to keep and remember how Down vm keep that information So down vm make two assumptions first the user always have two regions code and data Second the region size is fixed Right the second is kind of also true in this case in this assignment But the first is definitely not true some of the user program will have more than two segment Right, so you can assume that you don't know how many segments you need in that case was the more appropriate way to Maintain all those region information When you don't know how many entries you need if you know then you can use the array or Yeah, if you don't know then you use a link list. That's basically how you do it Right, so you can use a link list of all the region informations to keep where the regions Where is the region start address how large is the region? So inside the address structure you may have a small link list or to keep the region information and then Heap and stack is sort of a special region in the sense that Their size can change right for code and data region Their size is really fixed when you load them into memory, but for hip and stack their size change So those are two special regions where you want to do that you with them separately and of course you also want Page table pointer either is if you use a link list It can point to the first note of the link list page table links if you use a two-level page table You should have some information of where the best address of the first level page table is that Page table best variable you might want to if you want to use this design Then you will want to store this address somewhere in the address best structure So this is how What you should keep in the address best structure and Okay, so There are a couple of so whenever you have designed a structure You you always need to consider when how to initialize the variables inside a structure, right? So there are a couple of questions here. So first Where the heap so even before that how do you know where the code and data region is? So you have a small link list initially is empty when you do as create So you create an empty link list in the address space then When your user program gets running you should already have some information Have some knowledge of all the regions in the middle what happened? How do you initialize that link list of all the region informations? Any ideas? So how do you know where the region start and how large the region is I know but how do you get that information? No, how do you initialize the pointers? So how do you so how do you know the address of this? How do you know the address of this or how do you know the length of this? Yeah from the EFO file, but that's not part of the address space, right? That's kind of lot elf does see that in there Remember that last time when we talked about the interface of the address space We mentioned a way interface called as define region This is how the other part of the system, which is a lot elf tells you as a virtual address virtual memory system or about The region information where the reading start and how large it is and also when Extra piece of information is what's the permission of that region, right? So for example in SD file region The lot elf will tell you that here is one region it starts from here The size is how many bytes and the permission is executable read the only but not writeable This is the information you get from ASD fine region Right, so you can think of as a layer where they there are some entries in the layer is the is the interface call to the virtual memory system below that when you receive the ASD fine region call You are supposed to remember that information, right? That's how you figure out how many regions are there in the user address space So after that you have a code region a dead region and all that So now the next question is where the heap starts So if the fine region will only tell you that there's this region this region fixed size that we can know from the elf file But we don't know where the heap start That's another question you need to answer. I need to figure out but Intuitive think of the heap is that it's just because it grows downwards So we don't want the heap for example start from here Because if start from here, then soon after we will hit the code region, right? We are kind of limited by this so you want the heap region to be the last region that There is no reason after this heap region Okay, so you kind of get some idea of to decide where the heap start it should after all these regions Again, you have this information By Traversing all the regions and found the one with the Which is the latter one and you set the heap start to be right after that This is how you initialize the heap region and the second question is that So there is the trick thing about this code segment So not elf will tell you as a virtual memory system that now I'm going to defy region is It's a executable. It's readable but not a writable, right? Then okay You remember this information you keep that in the small link list of region information Then the lot of who will actually try to write to that region because that's how the love lot of works It read from the disk loading to memory by loading any mean right So if you do don't do anything special in the VN fault, you will really get confused because okay When you so you you will get a VN fault say on this virtual dress and you will get okay Somebody is trying to write to this address But according to the region information that all the virtual addresses inside this region are not writable It's only readable Should you reject it? normally you should right you should enforce this kind of permission and If somebody wants to write to read only patch you should reject that But this case is different though because this is the first time somebody ever tried to write to that region Actually, it's a lot of elf try to write there. You should allow that So there are two cases here when you receive a right to request to a read only patch right if it's a lot of elf you should accept it Otherwise lot of elf cannot do it does cannot do his job If it's not a lot of elf then you should reject it so you you sort of have a dilemma here of Have a hard time to determine how will you want to react to the right request to a read only patch right and This two function calls are the key to the solution So lot of elf is kind of polite in the sense that before lot of elf tried to write to a riddle read only region Say for example, this one it will cause function, which is a kernel function No user can call it call AS prepare a lot which basically tells the virtual memory system that I'm going to Law some content into memory and in the process. I might need to write to some write only patch Right so you can imagine what you can do in the prepare a lot You in inside AS prepare a lot you can sniff again all the regions if the region is all is not Rightable you set it as writable, but you also Make a backup of the original permission information Right, so even thought you don't have that confusion here If it says writable then it can write you even though the original permission may be May not be writable right, so in AS prepare a lot it allows you to do some bookkeeping to Be able to write to that code region Then after a lot of elf is done It will call another function called as complete lot which tells you that I'm done with a lot in now You can close the backdoor from now on All the requests should be enforced meaning that if somebody else want to write to this code region You should reject it Right, so you can imagine that yes as prepare a lot is kind of open a backdoor so that lot of elf can write to it and As complete lot is kind of a you close the backdoor don't allow any on authorize Oppression on the pages this part let me maybe Allowed for you to digest at this point if you haven't worked on it yet, but you will soon realize that The usefulness of these two functions At first you may think that this function is no use right dumb VM doesn't doesn't use it. That's because dumb VM Don't do this kind of smart thing of on-demand page allocation And once you once you have this you have to think of all the cases where the memory can be accessed Any questions on this? So Finally we have contact switches, which is so during contact switch is activated will be caught and inside Is activated with what I was supposed to do So how do you activate and address space? That's what I do, but why? Yeah, so TLB is one CPU only have one tail or one set of TLB, right? When you have different processes running on that same CPU if you don't flush the TLB entries when you Do contact switch the newer process will get confused about the virtual dresses because that word address mapping is not really my mapping Right, so every time you have a context which you should try to shoot down all the TLB entries To make sure that the newly scheduled process or thread has a clean slate has a clean TLB TLB buffer right and Again is that's okay to do in this assignment because Efficiency or performance is not a concern here, and you really think about it. It's really dumb, right? You should be able to differentiate TLB entries that belong to different processes That's kind of an advanced the feature of this but in this experiment What do you do really in is activate is just shoot down all the TLB entries It's the it's a brute force way to do it, but it works Okay So finally TLB we have been talking about TLB all the time But let's take a really crucial look of what the TLB really is So TLB as you already know is a hardware cache for a version of physical mapping again is a mapping It's a mapping from virtual page to physical page, but it's implemented in hardware So this is one TLB entry looks like and we have in total 64 entries per CPU core and Each entry is 64 bits each which can be divided into high and low So the upper 32 bit is higher 32 bit and lower is lower 32 bit so In the higher 32 bit the higher 20 bit Stores the virtual page number which is You can so all these values will be zero so you can view the entire higher 32 bit as a virtual address So because this is all always zero. This is terribly this virtual dress is always page aligned Right, so the higher 32 bit is the aligned virtual page address Now in the in the lower 32 bit. We have different Bit here so in the higher 32 bit again We have the physical page number which is the aligned physical address Divided by 4k you can see that as we this way if you mask all this as zero Then the lower 32 bit will be the physical address Because the all the addresses here are or 4k aligned so the lower 32 bit doesn't really get any use here But the TRBs have some special flags here in this region because this is not already always used and Some of the flags are as this They have a no cache flag. They have dirt flag and have a valid flag So for no cash, you don't need really to care about the cash stuff and what's important is these two flags so if one this flag is One was so the dirty flag is not what's the name suggests It actually means that whether or not this virtual dress is writable It's not a Flag indicating whether this page is dirty or not. It's actually a flag that the decide Whether this page can be written or not so say if this dirt bit is zero then If any user want to write to that virtual page When the hardware consults the TRB, okay, given a virtual dress I locate this TRB entry and I check the dirty bit if the dirty bit is zero And the operation is a right and the hardware will raise the TRB fault That's that's one kind of TRB fault, right? then if this bit is zero and The operation is read then everything is fine. I locate the TRB entry is the user want to read from it And it definitely can read from the TRB entry or let me put this way so When you have Whenever user want to access the virtual memory access memory as a hardware what do you get is to information One information is what's the virtual dress that user want to access the second information is what's the operation? The user want to do is a read write or execute Execute right you have this to information and then you carry your TRB buffer Right suppose you got a hit that you use the virtual page virtual Address as a key to query the TRB then you get this entry then you check this bit Right you have different combinations of the operation and this bit, right? One combination of them is that the operation is a right and the beta is zero In which case you should reject as a hardware You don't need you don't even this in the kernel. This is all done by the hardware But but it's a kernel's responsibility to set this So if a page is writable as in the heap and data segment you should set this flag to be one To indicate that user can actually write to this page Otherwise you will keep getting getting TRB fault because the user are supposed to be able to write to the page Now you are not giving the user the access to it So this is what the dirty bit does and also there's another bit called that it which is kind of simple If it's zero then it's a valid entry if it is not zero then it's not valid This one is quite simple. This one is a little bit tricky and There are some macros. I think there are functions to help you to deal with TRB You have functions like TRB probe which is kind of read the content of the TRB You have TRB read, TRB write and TRB random You can see the comments in the file to see what each function does But as a call of it you need to understand what the TRB looks like and what each bit What's the functionality of each bit? So as I just explained you will get three types of TRB fault Which is false read meaning that there is no such entry and user want to read from the address Fault write meaning that there is still no such TRB entry, but the user want to write to it And there is a third type of fault which is just what we have described in the corner case Where the user want to write to a virtual page There is already a mapping there just that the dirty bit in that mapping is zero So it's a special TRB fault called TRB fault read only So in VM fault you get what's the fault address? What's the fault type? This is two information you get in your VM fault handler, then you need given different combinations of the fault type and address you need to handle the KB fault So finally let's took a look at how to deal with the virtual fault So when you reach a VM fault, that's one function you wrote This is probably the most complete complicated function in this whole assignment. What do you know? so It depends on the fault type if it's a fault read or fault write You know that okay. There is no TRB entry for this mapping If it's a VM fault read only then you know that you know more information You know that there is already a TRB entry for that just the dirty bit is zero, but the user want to write to it right, so this is the information you get and so when you whenever you have a VM fault you first check if the fault address is a valid user address as We have seen in this figure There are plenty of empty regions in the user address address There's points to nowhere meaning that if you receive a VM fault that the the virtual address is Somewhere here or somewhere here. You know that it cannot be that case. It's a Invalid the user pointer and in that case you should reject that VM fault immediately, right? It's not so first you need to check if the virtual address is valid Then if it's valid, it must fall into one of the regions either code region data region heap or stack And the next step is to check the permission, right? Only in the I would say only the code region has a special permission, which is really only right You really need to check if it falls into the code region and the user want to write in that case You should reject that's the case where the The user can violate the permission of that page After you check the photo dress is a valid user pointer and oppression is valid Then you check whether is the page for the or not and you have I Think you have answered this in the coding questions to differentiate TWB fault versus page fault, right? When you have a VM fault you do not necessarily have a page fault It's just that it may be just that the page is already very in the memory There is just a no bridge in the TWB to connect the virtual to physical mapping, right? If that's the case then there is very little you need to do just to fix up the TWB entry Then you are done, right? That's the most simple is the case So check whether is a TWB fault or page fault or both right, that's the that's a thing you need to check and If it's a page fault, which means that there is you need to allocate a page or Necessity or not necessarily either allocate a blank fresh physical page or you need to swap in Page from the disk. We will talk about the letter case in the next specification And for now, let's assume that if it's a page fault Then you need to allocate a physical page Which you can use your allocator key pages or some other page allocation function You need to interact with the call map to reflect that that page has been already allocated, right? So once you get a hand of that physical page, you get the physical address You have virtual address, you have physical address Now it's time to update the TWB entry so that this mapping is correctly reflected in the TWB so this is the basic flow of how you handle the VM fault and Each step is tricky and you can you you might Find you might be confused in some every steps So it's important to get this whole picture in mind keep this whole picture in mind and know what they are doing in each step right So this is basically what I have today any questions on this You yeah Yeah, I rejected it. I mean kill the thread Yeah Because as a point, you know that a user program is male behaving So you know it's you should keep you should kill it and you should really get started working on this Otherwise, you have no idea of what I'm talking about right You should really get a call map done came one came to pass that move on to the page table design user respace All right. I'll see you next time