Tài liệu ARM Architecture Reference Manual- P18 ppt

Coarse second-level page tables must Virtual address Address of first-level descriptor Page table base address Second-leveltable index 0 0 First-level table index First-level table index

Trang 1

3.3.5 Coarse page table descriptor

If the first-level descriptor is a coarse page table descriptor, the fields have the following meanings:

Bits[1:0] Identify the type of descriptor (0b01 marks a coarse page table descriptor)

Bits[4:2] The meaning of these bits is IMPLEMENTATION DEFINED

Bits[8:5] The domain field specifies one of the sixteen possible domains for all the pages controlled

by this descriptor

Bit[9] This bit is not currently used, and should be zero

Bits[31:10] The Page Table Base Address is a pointer to a coarse second-level page table, giving the

base address for a second-level fetch to be performed Coarse second-level page tables must

Virtual address

Address of first-level descriptor

Page table base address Second-leveltable index 0 0

First-level table index

First-level table index Second-leveltable index

Address of second-level descriptor

10

10 S Z

Trang 2

3.3.6 Fine page table descriptor

If the first-level descriptor is a fine page table descriptor, the fields have the following meanings:

Bits[1:0] Identify the type of descriptor (0b11 marks a fine page table descriptor)

Bits[4:2] The meaning of these bits is IMPLEMENTATION DEFINED

Bits[8:5] The domain field specifies one of the sixteen possible domains for all the pages controlled

by this descriptor

Bit[11:9] These bits are not currently used, and should be zero

Bits[31:12] The Page Table Base Address is a pointer to a fine second-level page table, giving the base

address for a second-level fetch to be performed Fine second-level page tables must be aligned on a 4KB boundary

If a fine page table descriptor is returned from the first-level fetch, a second-level fetch is initiated to retrieve

a second-level descriptor, as shown in Figure 3-5

Figure 3-5 Accessing fine page table second-level descriptors

Translation table base

Virtual address

SBZ

Second-level table index

11 9

Trang 3

3.3.7 Second-level descriptor

Each entry in a coarse second-level table corresponds to how a 4KB virtual address range is mapped, and each entry in a fine second-level table corresponds to how a 1KB virtual address range is mapped The entries are page descriptors, and can describe a page which is larger than 4KB or 1KB respectively When this happens, the descriptor must be repeated enough times in the second-level table to ensure that the same descriptor is always used for the page, regardless of which virtual address is being accessed within the page.There are four possibilities for a second-level descriptor, selected by bits[1:0] of the descriptor as shown in Table 3-2:

generate a translation fault (see Aborts on page B3-18) Software can use bits[31:2] for its own

purposes in such a descriptor, as they are ignored by the hardware Where appropriate, it is suggested that bits[31:2] continue to hold valid access permissions for the descriptor

• If bits[1:0] == 0b01, the entry is a large page descriptor, describing 64KB of virtual addresses See

Translating large page references on page B3-13 for details.

A large page descriptor must be repeated 64 times in a fine second-level table or 16 times in a coarse second-level table to ensure that all of its virtual addresses are described

• If bits[1:0] == 0b10, the entry is a small page descriptor, describing 4KB of virtual addresses See

Translating small page references on page B3-14 for details.

A small page descriptor must be repeated four times in a fine second-level table to ensure that all of its virtual addresses are described In a coarse second-level table, only one instance of each small page descriptor is needed

• If bits[1:0] == 0b11, the entry is a tiny page descriptor, describing 1KB of virtual addresses See

Translating tiny page references on page B3-15 for details.

Only one instance of each tiny page descriptor is needed in a fine second-level table Tiny page descriptors must not appear in coarse second-level tables If they do, the results are UNPREDICTABLE

Table 3-2 Second-level descriptor format

Trang 4

Large page descriptor fields

The fields in a large page descriptor have the following meanings:

Bits[1:0] Identify the type of descriptor

Bits[3:2] Are the cachable and bufferable bits (see Cachability and bufferability on page B5-8).

Bits[11:4] Are the access permission bits These bits control access to the page See Table 3-3 on

page B3-16 for the interpretation of these bits Large pages are split into four subpages:

Bits[15:12] Are not currently used, and must be zero

Bits[31:16] Are used to form the corresponding bits of the physical address

Small page descriptor fields

The fields in a small page descriptor have the following meanings:

Bits[11:4] Are the access permission bits These bits control access to the page See Table 3-3 on

page B3-16 for the interpretation of these bits Small pages are split into four subpages:

Tiny page descriptor fields

The fields in a tiny page descriptor have the following meanings:

Bits[5:4] Are the access permission bits See Table 3-3 on page B3-16 for the interpretation of these

bits, which apply to the entire tiny page

Bits[9:6] Are not currently used, and must be zero

Trang 5

3.3.8 Translating large page references

Figure 3-6 shows the complete translation sequence for a 64KB large page in a coarse second-level table The translation sequence for a large page in a fine second-level table is similar, but with the address of the

second-level descriptor being determined as shown in Fine page table descriptor on page B3-10

Note

As the upper four bits of the Page Index and low-order four bits of the Second-level Table Index overlap, each page table entry for a large page must be repeated 16 times (in consecutive memory locations) in a coarse page table Similarly, each page table entry for a large page must be repeated 64 times in a fine page table

Second-level fetch

Large page base address AP3 AP2 AP1 AP0 B 0 1

Virtual address

First-level

Z table index level table index

Trang 6

3.3.9 Translating small page references

Figure 3-7 shows the complete translation sequence for a 4KB small page in a coarse second-level table The translation sequence for a small page in a fine second-level table is similar, but with the address of the

second-level descriptor being determined as shown in Fine page table descriptor on page B3-10.

Note

When a small page appears in a fine second-level table, the upper two bits of the Page Index and the low-order two bits of the Second-level Table Index overlap So each page table entry for a small page must

be repeated four times (in consecutive memory locations) in a fine page table

Figure 3-7 Small page translation in a coarse second-level table

Small page base address AP2 AP1 AP0 B 1 0

Virtual address

Trang 7

3.3.10 Translating tiny page references

Figure 3-8 shows the complete translation sequence for a 1KB tiny page in a fine second-level table

Note

Tiny pages can not appear in a coarse second-level table

Figure 3-8 Tiny page translation in a fine second-level table

Tiny page base address SBZ AP B 1 1

Virtual address

12 9

11 12

10 9 Page index

Trang 8

3.4 Access permissions

The access permission bits in section and page descriptors control access to the corresponding section or page The access permissions are modified by the System (S) and ROM (R) control bits in CP15 register 1 Table 3-3 describes the meaning of the access permission bits in conjunction with the S and R bits If an access is made to an area of memory without the required permission, a Permission Fault is raised (see

0b00 1 1 UNPREDICTABLE UNPREDICTABLE

Trang 9

3.5 Domains

A domain is a collection of sections, large pages and small pages The ARM architecture supports 16 domains Access to each domain is controlled by a 2-bit field in the Domain Access Control Register Each field allows the access to an entire domain to be enabled and disabled very quickly, so that whole memory areas can be swapped in and out of virtual memory very efficiently Two kinds of domain access are supported:

Clients Are users of domains (execute programs, access data), and are guarded by the access

permissions of the individual sections and pages that make up the domain

Managers Control the behavior of the domain (the current sections and pages in the domain, and the

domain access), and are not guarded by the access permissions of individual sections and pages in the domain

One program can be a client of some domains, and a manager of some other domains, and have no access

to the remaining domains This allows very flexible memory protection for programs that access different memory resources Table 3-4 illustrates the encoding of the bits in the Domain Access Control Register

Table 3-4 Domain Access Values Value Access types Description

section or page descriptor

section or page descriptor, so a permission fault cannot be generated

Trang 10

3.6 Aborts

Mechanisms that can cause the ARM processor to halt execution because of memory access restrictions are:

MMU fault The MMU detects the restriction and signals the processor

External abort The external memory system signals an illegal memory access

Collectively, MMU faults and external aborts are just called aborts Accesses that cause aborts are said to

be aborted

If the memory request that is aborted is an instruction fetch, then a Prefetch Abort exception is raised if and when the processor attempts to execute the instruction corresponding to the illegal access If the aborted

access is a data access, a Data Abort exception is raised See Exceptions on page A2-13 for more

information about Prefetch and Data Aborts

Aborts that are detected by the MMU are stopped before any external memory access takes place It is the responsibility of the external system to stop external accesses that cause external aborts

The System Control coprocessor contains two registers which are updated when a data access is aborted These registers are not updated for Prefetch Aborts, as the aborted instruction might not be executed due to changes in program flow

Fault Address Register (FAR) and Fault Status Register (FSR)

Aborts resulting from data accesses (Data Aborts) are immediately acted upon by the CPU The Fault Status Register (FSR) is updated with a 4-bit Fault Status (FS[3:0]) and the domain number of the access In addition, the virtual address which caused the Data Abort is written into the Fault Address Register (FAR)

If a data access simultaneously generates more than one type of Data Abort, they are prioritized in the order given in Table 3-5 on page B3-19

Aborts arising from instruction fetches are flagged as the instruction enters the instruction pipeline Only when (and if) the instruction is executed does it cause a Prefetch Abort exception An abort resulting from

an instruction fetch is not acted upon if the instruction is not used (for example, if it is branched around) Normally, the fault address associated with a Prefetch Abort exception is determined from the value saved

in R14_abt when the Prefetch Abort exception vector is entered It is IMPLEMENTATION DEFINED whether

Trang 11

the FSR and FAR are updated for an abort arising from an instruction fetch, and if so, what useful information they contain about the fault However, an abort arising from an instruction fetch will never update the FSR and the FAR between the time that an abort arising from a data access updates them and the time of the corresponding entry into the Data Abort exception vector In other words, a Data Abort handler can rely upon its FAR and FSR values not being corrupted by an abort arising from an instruction fetch that was not acted upon.

Note

Alignment faults can write either 0b0001 or 0b0011 into FS[3:0]

Invalid values in Domain[3:0] occur because the fault is raised before a valid domain field has been loaded.Any abort masked by the priority encoding can be regenerated by fixing the primary abort and restarting the instruction

The FS[3:0] encoding for Vector Exception breaks from the pattern that FS[0] is zero for all external aborts

Table 3-5 Priority encoding of fault status

Second level

0b11000b1110

InvalidValid

ValidValid

Page

0b01010b0111

InvalidValid

ValidValid

Page

0b10010b1011

ValidValid

Page

0b11010b1111

ValidValid

Page

0b01000b0110

ValidValid

Non-linefetch

SectionPage

0b10000b1010

ValidValid

Trang 12

No access Client

No

Yes

No

Yes No

Yes

Page Section

Yes

Check address alignment

Get first-level descriptor

Check access permissions

Check domain

Check access permissions Check domain Get second-level descriptor

Virtual address

Checking alignment?

Misaligned?

External abort

Descriptor fault

External abort

Invalid descriptor?

Access type

Violation?

Physical address

Access type

Violation?

Translation external abort

Page translation fault

Alignment fault Translation

external abort

Page domain fault

Sub-page permission fault

Section permission fault

Section domain fault

Yes

No No

No

Manager

No

No access

Client

Section or page?

Section translation fault

Trang 13

Terminal exception

This indicates that an irrecoverable fault has occurred The circumstances under which this can happen (if

at all) are IMPLEMENTATION DEFINED

Vector exception

When the processor is in a 32-bit configuration (PROG32 is active) and in a 26-bit mode (CPSR[4] == 0),

data access (but not instruction fetches) to the normal exception vectors (address 0x0 to 0x1F) cause a Data Abort, known as a vector exception It is IMPLEMENTATION DEFINED if vector exceptions are generated when

the MMU is not enabled For more information, see Vector exceptions on page A8-11.

Alignment fault

If alignment faults are enabled, an alignment fault is generated on any data word access whose address is not word-aligned (virtual address bits [1:0] != 0b00), or any halfword access that is not halfword-aligned (virtual address bit[0] != 0) Alignment faults are not generated on any instruction fetch, or on any byte access

Note

If the access generates an alignment fault, it is aborted without reference to further permission checks It is

IMPLEMENTATION DEFINED if alignment exceptions are generated when the MMU is not enabled

Translation fault

There are two types of translation fault:

Section This is generated if the first-level descriptor is marked as invalid This happens if bits[1:0]

of the descriptor are both 0

Page This is generated if the second-level descriptor is marked as invalid This happens if

bits[1:0] of the descriptor are both 0

Domain fault

There are two types of domain fault:

In both cases, the first descriptor holds the 4-bit Domain field which selects one of the sixteen 2-bit domains

in the Domain Access Control Register The two bits of the specified domain are then checked for access permissions as detailed in Table 3-4 on page B3-17:

• In the case of a section, the domain is checked when the first-level descriptor is returned

Trang 14

Permission fault

There are section permission faults and subpage permission faults

Permission faults are checked at the same time as domain faults If the 2-bit domain field returns client (01), the permission access check is invoked as follows:

Section If the first-level descriptor defines a section access, the AP bits of the descriptor define

whether or not the access is allowed, according to Table 3-3 on page B3-16 If the access is not allowed, a section permission fault is generated

Subpages If the first-level descriptor defines a page-mapped access, the second-level descriptor can

define a tiny page, a small page or a large page If the second-level descriptor defines a tiny page, it contains a single access permission field (AP), which applies to the whole page Otherwise, the second-level descriptor contains four access permission fields (AP3, AP2, AP1, AP0), each corresponding to one quarter of the page

For small pages, AP3 is selected by the top 1KB of the page, and AP0 is selected by the bottom 1KB of the page For large pages, AP3 is selected by the top 16KB of the page, and AP0 is selected by the bottom 16KB of the page The selected AP bits are then interpreted

in exactly the same way as for a section, (see Table 3-3 on page B3-16) the only difference being that the fault generated is a subpage permission fault

3.6.2 External aborts

In addition to the MMU faults, the ARM architecture defines an external abort pin which can be used to flag

an error on an external memory access However, not all accesses can be aborted in this way, so this pin must be used with great care The following accesses can be externally aborted and restarted safely:

A linefetch can be safely aborted on any word in the line transfer If the abort happens on data that has been requested by the processor (rather than data that is being fetched as the remainder of a cache line), the access

is aborted Any data transferred that is not immediately accessed (the remainder of the cache line) is only aborted when it is accessed

It is IMPLEMENTATION DEFINED if the FAR points to the start address of the cache line, or the address that generated the abort

Buffered writes cannot be externally aborted Therefore, the system must be configured so that it does not

do buffered writes to areas of memory which are capable of flagging an external abort, or a different mechanism needs to be used to signal the abort (an interrupt for example)

The value of a memory location that causes an abort is UNPREDICTABLE after the abort

Trang 15

3.7 CP15 registers

The MMU is controlled with the System Control coprocessor registers 2, 3, 4, 5, 6, 8 and 10, and some bits

of register 1

3.7.1 MMU control bits in register 1

The following bits in the System Control coprocessor register 1 are used to control the MMU:

M (bit[0]) This is the enable/disable bit for the MMU:

0 = MMU disabled

1 = MMU enabled

On systems without an MMU or Protection Unit, this bit must read as zero and ignore writes

A (bit[1]) This bit enables and disables alignment fault checking (see Alignment fault on page B3-21):

0 = Alignment fault checking disabled

1 = Alignment fault checking enabled

S (bit[8]) This is the system protection bit The effect of this bit is described in Access permissions on

page B3-16

R (bit[9]) This is the ROM protection bit The effect of this bit is described in Access permissions on

page B3-16

3.7.2 Register 2: Translation table base

Reading from CP15 register 2 returns the physical address of the currently active first-level translation table

in bits[31:14] and an UNPREDICTABLE value in bits[13:0] The CRm and opcode2 fields are ignored when reading CP15 register 2 and should be zero

Writing to CP15 register 2 updates the physical address of the currently active first-level translation table from the value in bits[31:14] of the written value Bits[13:0] must be written as zero or as a value previously read from bits[13:0] of this register The CRm and opcode2 fields are ignored when writing CP15 register 2 and should be zero

Tiêu đề	Memory Management Unit: Coarse and Fine Page Table Descriptors
Trường học	Not specified
Chuyên ngành	Computer Architecture
Thể loại	Documentation
Năm xuất bản	2000
Thành phố	Not specified

Định dạng
Số trang	30
Dung lượng	444,44 KB