Method and Apparatus for TLB Invalidation Mechanism for Protective Page Fault

1. Field of the Invention

The present invention relates generally to a method and apparatus for TLB (Translation Lookaside Buffer) invalidation mechanism for protective page fault in a X86 system. The invention particularly relates to a method and apparatus which applies a modification mechanism to invalidate the TLB entry of a protective fault page with only one-time TLB table walk.

2. Description of the Prior Art

A TLB (Translation Lookaside Buffer) is an on-chip cache that references the most recently used page table entries and translates linear addresses into physical addresses directly without having to access page tables and page directories from the main memory. The TLB is usually organized as an eight-set by four-way association of linear-address tags and physical-address datum, with related LRU and protection bits. When paging is enabled in the Protected mode, a processor's TLB references the most recently used page table entries. Then, the TLB translates linear addresses into physical addresses without having to access page tables and page directories from the main memory.

Page fault refers to a situation that the processor can retry (re-start). Page faults often occur during normal operation, such as when a new page must be loaded from disk into memory. When a service routine handles a fault, its return address points to the instruction that caused the fault so that the instruction can be retried. In a X86 computer architecture, when protective page fault occurs, the system has to apply protective page fault service routine to flush all the TLB entry, that is, invalidate all the TLB valid entries to ensure the correspondence between the entries of the page table and that of the TLB after modification. This approach reduces overall performance of the system significantly.

There is another approach which does not rely on protective page fault service routine to flush the TLB, but has to execute TLB table walk twice. This also reduces overall performance of the system.

Advanced operating systems which employs copy-on-write operating systems, such as Linux, usually will not make a copy for shared data. Instead, it sets the shared data of a page table as read-only mode, When a page with shared data has to be updated and is executing write instruction, page fault occurs. At this time, the operating system applies page fault service routine to make a copy of the page and then change the mode of both pages (the original page and the copy) to read/write mode. For such advanced operating systems, the two approaches for protective page fault stated above will reduce the performance of the system more apparently.

Accordingly, it is the primary object of the present invention to provide an improved method and apparatus for TLB invalidation mechanism for protective page fault to improve system performance.

Briefly described, the present invention encompasses a method for TLB invalidation mechanism for protective page fault. The steps of the inventive method include: (1) detecting the occurrence of protective page fault; (2) executing protective page fault processing mechanism; (3) invalidating the TLB entry for protective fault page; (4) executing protective page fault service routine; herein the TLB entry for the protective fault page has been invalidated; (5) returning to the address where protective page fault occurs; (6) executing TLB table walk to complete the modification for protective page fault; and step (6) executes TLB table walk only once.

The present invention which outputs an invalidate signal to invalidate the TLB entry for protective fault page further encompasses: invalidate address generator for generating an invalidate address input to TLB; TLB invalidation control device for inputting a signal which indicates protective page fault and a signal which indicates invalidate request and for outputting an invalidate control signal to TLB; and invalidating the TLB entry for protective fault page in response to the invalidate address and the invalidate control signal.

These and other objects and advantages of the present invention will become apparent by reference to the following description and accompanying drawings wherein:

FIG. 1 is a schematic diagram showing the mechanism for protective page fault according to the prior art.

FIG. 2 is a schematic diagram showing the mechanism for protective page fault according to another prior art.

FIG. 3 is a schematic diagram showing the TLB invalidation mechanism for protective page fault according to the present invention.

FIG. 4 is a block diagram showing the function blocks of the preferred embodiments according to the present invention.

FIG. 1 shows a modification mechanism for protective page fault according to the prior art. The detailed description for the execution steps are stated below:

10: protective page fault occurs;

11: protective page fault processing mechanism detects protective page fault and enables protective page fault service routine 12;

12: execute protective page fault service routine;

121: load page fault status/address register;

122: process/modify page table entities to ensure the entries of the page table be correct;

Please note that at step 121 and step 122, the TLB entry of protective fault page is valid.

123:.TLB entry are flushed and invalidated;

124: return to the address where page fault occurs;

13: execute TLB table walk;

At this time, since all the TLB, entry are invalidated, so when the system is executing TLB table walk 13, it will write the page table entry for protective page fault, processed/modified at step 122 into the TLB.

14: complete protective page fault modification.

The protective page fault processing mechanism 11 of FIG. 1 does not flush TLB entries. Instead, it relies on step 123 of protective page fault service routine 12 to flush TLB. This approach will invalidate all the TLB entries even though most TLB entries are correct and not have to execute TLB table walk. Therefore, it will reduce system performance significantly.

FIG. 2 shows another approach according to the prior art. The detailed description for the execution steps are described below:

20: protective page fault occurs;

21: execute TLB table walk 21 which writes the entry of a page table into TLB.

However, since the entry of the page table have not been modified yet, so the data just written in the TLB is still incorrect;

22: execute protective page fault processing mechanism;

23: execute protective page fault service routine;

231: load page fault status/address register;

232: process/modify page table entities to ensure the entries of the page table be correct;

233: return;

24: return to the address where page fault occurs;

However, at this time, page fault in the TLB still exists and fault page is still valid. Thus, protective page fault occurs again. Step 21 executes TLB table walk once more which writes page table entities modified at step 232 into the TLB. Now protective page fault processing mechanism at step 22 detects no page fault, so it does not go to step 27. Instead, it goes to step 25.

26: complete the modification of protective page fault,

FIG. 3 is a schematic diagram showing the TLB invalidation mechanism for protective page fault according to the present invention. The detailed description for the execution steps are described as follows:

30: protective page fault occurs;

31: execute protective page fault processing mechanism; protective page fault processing mechanism 31 has two functions: one is detecting the occurrence of protective page fault; the other is invalidating the TLB entry of protective fault page which is different from prior arts.

32: execute protective page fault service routine;

321: load page fault status/address register;

322: process/modify page table entities, that is, modify page table entries for fault page;

323: return;

33: return to the address where page fault occurred;

34: execute TLB table walk;

At this time, since the TLB entry for protective fault page has been invalidated before the execution of protective page fault service routine 32 and the steps that follows, including step 321, 322, and 323, therefore TLB table walk 34 is executed. The entry of page table which has been modified at step 322 is written to TLB, and validate the TLB entry of protective fault page.

35: complete the modification of protective page fault.

The main difference between FIG. 1 and FIG. 3 is that FIG. 3 does not need to flush TLB at step 123 which may invalidate TLB entry of protective fault page and then cause the occurrence of protective fault page. Furthermore, flushing TLB at step 123 also stops other correct and valid pages from being continuously used. They have to stay idle until next time when TLB table walk is executed. As mentioned above, this approach is very inefficient and will reduce system performance very significantly. In contrast, according to FIG. 3, the invention only invalidates TLB entry of protective fault page, not all the entries.

The main difference between FIG. 2 and FIG. 3 is that whenever protective page fault occurs, FIG. 2 has to execute TLB table walk twice to modify protective page fault. In contrast, the invention only needs to execute TLB table walk once to complete the modification of protective page fault.

FIG. 4 shows the function blocks according to the present invention. Invalidate address generator 40 consists of invalidate linear address 401, page fault address register 402 and MUX 403. TLB 41 consists of TAG's CAM (Content Addressable Memory) 411 and DATA's RAM 412. In addition, there is a TLB invalidation control device 44. All these devices constitute the TLB invalidation mechanism for protective page fault according to the invention.

Please refer to FIG. 4, Invalidate linear address 401 is a system invalidation request sent from the system. Page fault address register 402 stores page fault address. The inputs of MUX 403 are invalidate linear address 401 and page fault address from page fault address register 402 . The output of MUX 403 is invalidate address 404 which is delivered to TAG's CAM 411 of TLB 41. TLB invalidation control device 44 receives two signal inputs: one indicating protective page fault 42 and the other indicating invalidate request 43. TLB invalidation control device 44 outputs an invalidate control signal 45 to TAG's CAM 411 of TLB 41. Since invalidate address 404 and invalidate control signal 45 are sent to TAG's CAM 411 to set V=0, therefore the valid entries indicated by the page fault address 413 are invalidated. DATA's RAM 412 then writes correct page table into page base 414 during TLB table walk according to page base 414 indicated by page fault address 413. DATA's RAM 412 sets V=1 to validate the valid entries of page fault address 413. Thus, the invalidation mechanism for protective page fault is finished.

The primary advantage of the invention is that it contains the TLB invalidation mechanism for protective page fault in the protective page fault processing mechanism. Thus, as soon as protective page fault process is finished, modified page table entries can be correctly loaded into the TLB automatically during TLB table walk without having to use software routines to flush TLB.

Another advantage of the invention is that it is flexible and can improve system performance. The invention can be implemented in hardware or micro code according to the structure of FIG. 4.

It should be understood that various alternatives to the structures described herein may be employed in practicing the present invention. It is intended that the following claims define the invention and that the structure within the scope of these claims and their equivalents be covered thereby.