PCIe Chapter 27: ATS, PRI, and PASID Address-Translation Flows

Place the translation participants before tracing DMA

DMA

Direct Memory Access, device access to memory

Figure 10-1 places the device ATC, platform TA and ATPT (Address Translation and Protection Table). TA and table may be integrated or separate. Figure 10-2 then traces the lookup before actual DMA (Direct Memory Access).

Simulated data: the single Endpoint Function uses RID=0300h and PASID=00021h, is in D0 with Bus Master Enable set, and has platform authorization for these services. The path accepts the example packets; TC0/TC1 transport is ready. The numeric case uses Non-Flit Mode without Reset, Replay or PASID stop/reuse events. These are author assumptions, not hardware observations.

RID

Routing ID, the packet routing identity

PASID

Process Address Space ID

Base 6.0 Chapter 10 and §6.20 define the protocol. Platform page tables, IOMMU (Input/Output Memory Management Unit) registers and OS interfaces need their own documents. Switches can transparently forward ATS; they need not become TAs or implement ATS Requester Capabilities.

Base 6.0 §10.1.1, Figures 10-1/10-2, pp.1470–1474.

Equal PASIDs do not identify an address space across Functions

Under §6.20 combine PASID with Requester ID. RID 0310h using PASID 21h is not thereby the same address space as RID 0300h/PASID 21h. PASID is not a universal OS PID encoding; mapping it to Function work context is device/platform specific.

RID

Routing ID, the packet routing identity

Figure 6-20/Table 6-15 locates the Non-Flit End-End Prefix. Execute Requested=0, Privileged Mode Requested=0 and PASID=00021h produce bytes 91 00 00 21. Flit Mode uses OHC-A1, a header block carrying PASID and related information. The Translation Request No Write bit also belongs in this block.

Max PASID Width=8 permits values 0–255, including 21h and 0. Hardware must not invent reserved PASID values. Ordinary Completions, including Translation Completions, must not carry PASID. Recover the original query's PASID through Requester ID/Tag context. PRG (Page Request Group) Response is a separately permitted Message type.

When Translated Requests with PASID is enabled and this mapping was obtained with PASID=21h, a Translated Request using it must carry the same PASID. Execute Requested and Privileged Mode Requested must also match the translation response Exe and Priv values respectively. If the translation was obtained without PASID, its corresponding Translated Request must not carry PASID. The permission fields are decoded later in this lesson.

Base 6.0 §§6.20–6.20.2.2, Figure 6-20/Table 6-15, pp.791–793; §10.1.3, pp.1477–1478.

Read three separate capability structures

Locate PASID ID 001Bh, ATS ID 000Fh and Page Request ID 0013h, all Version 1 in this edition, with bases P, A and R. Figures 7-185, 10-29 and 10-33 locate the following fields:

PASID Capability value 0808h advertises an 8-bit width and Translated Requests with PASID support. Execute/Privileged operation is not requested. Control value 0009h enables PASID and translated Requests with PASID. Configure PASID while ATS Enable=0, then set ATS Control value 8000h. Changing any PASID Control bit while ATS is enabled has undefined behavior.

STU (Smallest Translation Unit)=0 means 2⁰×4 KiB=4 KiB, not disabled translation. Invalidate Queue Depth=4 concerns invalidation buffering, not Page Request allocation. AMA is not enabled in this example.

While Page Request Enable=0, allocate 3 of Capacity 4 and verify Stopped=1 before enabling. Changing Allocation while enabled is undefined; enabling before successful stop is indeterminate. Stopped is meaningful only when Enable=0, not a live outstanding-request indicator while enabled.

ATS need not support PRI, and PASID is independent of both. Root Complex PASID support/enable mechanisms are implementation specific; do not assume an Endpoint PASID Control exists in the Root Port.

Base 6.0 §7.8.9, Figures 7-185–7-188, Tables 7-159–7-161, pp.1148–1151; §10.5.1, Figures 10-29–10-32, Tables 10-9–10-11, pp.1513–1516; §10.5.2, Figures 10-33–10-36, Tables 10-13–10-15, pp.1516–1520.

How do ATS capability and control fields affect the example?

Find ATS in the Extended Capability list. Figure 10-30 and Table 10-9 define ID 000Fh, Version 1, and Next Capability Offset relative to Configuration Space. Call the discovered structure base A; Figure 10-29 places the 16-bit ATS Capability at A+04h and 16-bit ATS Control at A+06h.

In the earlier author-created non-VF example, Capability=0024h and Control=8000h. Figure 10-31 and Table 10-10 give Queue Depth=4, Page Aligned Request=1, and zero for Global Invalidate Supported, Relaxed Ordering Supported, and ATS Memory Attributes Supported. This is one function's snapshot.

On a phone, scroll the table sideways to see all columns.

Figure 10-32 and Table 10-11 show E=1 and STU=0 in the example: translation caching is enabled and the smallest translation unit is 4 KiB. For a separate teaching value STU=2, 2² × 4 KiB = 16 KiB. STU is a minimum translation/invalidation unit, not the complete Translation Request length.

AMAE permits the Requester to provide AMA in a TPH TLP Prefix; when AMAE is set, AMAD provides a default AMA and the corresponding optimization. With AMAE=0 in this case, AMAD does not establish enabled use. Table 10-11 lists zero as the default for STU, AMAD, AMAE and E. If the Endpoint supports PASID, changing any PASID Control bit while ATS E=1 has undefined behavior.

TPH

TLP Processing Hints

TLP

Transaction Layer Packet

In SR-IOV, VF and PF ATS capabilities can be enabled independently, but VF Invalidate Queue Depth and STU are hardwired to zero and the associated PF values apply. Do not infer a VF's usable depth or STU from those zeros alone. Base 6.0 §10.5.1–§10.5.1.3, Figures 10-29–10-32 and Tables 10-9–10-11, pp.1513–1516. Device Control Enable Relaxed Ordering is in Table 7-21, p.960.

SR-IOV

Single Root I/O Virtualization

VF

Virtual Function

PF

Physical Function

Read four bytes at untranslated address 40001234h

Table 10-1 separates AT (Address Type): 00b is Untranslated, 01b is Translation Request, and 10b is Translated. AT00b does not universally mean CPU virtual address; the TA determines its interpretation. AT10b does not guarantee bypass of platform protection checks.

With Page Aligned Request=1, align the query to 40001000h. Figures 10-10/10-11 describe the MRd (Memory Read) with AT=01b. The TA returns the translation in a CplD (Completion with Data). Length=2 DW asks for at most one 8-byte translation entry, not eight application bytes. NW (No Write)=1 requests read-only use.

DW

Double Word, a four-byte unit

Decode Figure 10-14/Table 10-3: S=0 means 4 KiB; R=1, W=0, U=0 permits an appropriately scoped translated Read. Assume Global, Priv, Exe, N, AMA are zero. The page offset is 234h, so 90000000h + 234h = 90000234h. Its page is 90000000h–90000FFFh, and the four bytes do not cross it.

Memory Read Tag 2Bh is a new Transaction. Only the example's observed SC (Successful Completion) with four application bytes establishes that Read's result. Query Tag 2Ah completed the translation lookup. A Translation Request is not a flushing/ordering primitive for previous Writes.

Base 6.0 §§10.2.1–10.2.2, Table 10-1, Figures 10-6–10-13, pp.1478–1483; §10.2.3, Figure 10-14/Table 10-3, pp.1484–1489; §10.2.4, p.1496. Mode-specific base Headers: Chapter 14.

How does Length request two translations?

Continue the teaching example with STU=0 and Page Aligned Request=1. Starting at 40001000h, request translations for two consecutive 4 KiB regions. Length=4 DW permits up to two translation entries: each is 8 bytes and represents one or more STUs. Length describes the translation information that may be returned, not the application's data size. The TA may return fewer entries, but not more than requested; decode each returned entry's range and permissions before using a mapping.

Under §§10.2.2.2 and 10.2.2.4, the implied request range is 2⁰⁺¹² × (4÷2) = 8 KiB. Length must indicate an even number of DWs and must not exceed the limit determined by the Root Port's Read Completion Boundary (RCB). An odd Length or one above the permitted limit is treated by the TA as a Malformed Packet.

Figures 10-10–10-13 separate the modes: in Non-Flit Mode, NW is in the Request Header; in Flit Mode, OHC-A1 is required and contains NW. NW=1 requests read-only access, but the TA may ignore that hint, so check the Translation Completion's R/W fields. In Flit Mode, NW=0 also requires explicit write permission; NW alone does not establish authorization.

With a PASID, the untranslated address is within that PASID's process address space. Tag has the same meaning as in Memory Read and helps match the translation response to its Request. A Translation Request is not a flushing or ordering primitive for other transactions.

Base 6.0 §§10.2.2.1–10.2.2.6, Figures 10-10–10-13, pp.1481–1483; address type: §10.2.1, Table 10-1, pp.1478–1480.

How do two Completion packets carry two translations?

Continue the teaching request for two translations. The TA may return one or two; when it returns multiple entries, their translated ranges must have equal size and cover adjacent untranslated address ranges. A successful Translation Completion uses one or two CplDs, each containing whole translation entries.

Teaching example: the TA returns both 8-byte entries in two CplDs, and the Root Port RCB is 64 bytes. Both CplDs use the Requester ID and Tag of the original Translation Request.

Using §10.2.3 and Figures 10-15–10-16, the first Lower Address is 64−16=48 (30h), and the second is 0. These values satisfy RCB semantics; they are not the low bits of the original untranslated address. Decode the range and permissions of each entry separately using Figure 10-14.

Returning only one entry is not itself an error. An R=W=0 entry can describe a hole in the returned range, but the TA cannot add such entries merely to pad truncated results. Distinguish a returned no-permission range from a later range that was not returned.

Base 6.0 §10.2.3, Figures 10-14–10-16, pp.1485–1493; §10.2.4 Completions with Multiple Translations, p.1496.

How is a translation larger than 4 KiB decoded?

The earlier teaching entry uses S=0 for a 4 KiB range. For S=1, locate S and Translated Address in Figure 10-14, then read Table 10-5: starting at address bit 12, the run of 1s and the next 0 encode the range size. Those low bits convey size and cannot simply be interpreted as ordinary address bits.

Teaching example: S=1 and the encoded Translated Address is 90001000h, with bit 12=1 and bit 13=0. Table 10-5 gives 16 KiB; removing the low size-encoding bits gives 90000000h–90003FFFh. Assume R=1, W=0 and U=0; use the permission together with the Request identity and other applicable conditions.

S encodes size in units based on 4 KiB; STU is the Function's configured minimum translation unit. STU=2 means 16 KiB, so this range meets that minimum. For STU=3, the minimum is 32 KiB, and the Function must treat this 16 KiB Translation Completion as UR (Unsupported Request).

Also read N (Non-snooped). If N=1, Memory Reads and Writes using the translation must clear No Snoop in the Request. N=0 does not require No Snoop to be set: Function behavior and Device Control Enable No Snoop still apply. When U=1, N is undefined and cannot determine a later Request's attributes.

Base 6.0 §10.2.3, Figure 10-14 and Table 10-3, pp.1485–1486; §§10.2.3.1–10.2.3.3 and Table 10-5, pp.1487–1488.

SC does not replace permission decoding

With R=W=0 the range still has meaning, but address and specified other fields are undefined. A later invalid-to-valid mapping change need not send invalidation, so the ATC must not retain this entry as a persistent negative cache.

U (Untranslated access only)=1 permits caching the specified permission/range information, not using the returned address in AT10b Requests. A later need to Write with a read-only entry requires a fresh translation and authorization, not editing W in the ATC.

Table 10-2's UR (Unsupported Request) and CA (Completer Abort) are no-data failure responses. UR requires the Function to disable its ATC and stop using translated addresses until the ATC is re-enabled. CA means an error in the TA prevented translation. The RRS retry status is not permitted for Translation Requests and is treated as Malformed TLP when received; the preceding chapter's Configuration RRS conditions do not apply. None of these results alone identifies page non-residence or one failed platform component.

Base 6.0 §10.2.3, Table 10-2 Translation Completion with No Data Status Codes, p.1484; §§10.2.3.1–10.2.3.5, pp.1487–1489.

One invalidation can require more than one reply

Suppose the platform changes PASID 21h's mapping for 40001000h–40001FFFh. Use the mode-specific Figures 10-18/10-19 and Figure 10-20's untranslated range. Assume ITag 3, TC0, a 4 KiB range for this PASID only, and no Global Mapping.

New Requests must not use stale translations. Related outstanding Reads must complete or be marked for discard; Posted Writes must be pushed to the TA. Deleting the ATC entry alone is insufficient. Section 10.3.6 also handles an overlapping outstanding Translation Request so a delayed old result does not repopulate the cache after invalidation.

For this multi-TC continuation, assume the Function later needed to Write, requested a new translation, and obtained R=W=1 before issuing relevant Posted Writes on TC0 and TC1. Replies on these two channels provide the required push. Figure 10-5 illustrates multiple Invalidate Completions for one Request. Figures 10-21/10-22 identify the replies as Msg, Code 02h, ID routed, not ordinary Cpl packets. ITag Vector bit 3 identifies ITag 3:

Both carry CC (Completion Count)=2 and vector 00000008h. The first leaves one response outstanding. Only after both arrive can the TA consider this invalidation complete and release ITag. CC encoding 0 means eight messages, not none. ITag, Memory Request Tag and PRI PRG Index are separate mechanisms.

These semantics cover invalidation and push to the TA, not application persistence; memory reclamation needs platform lifecycle coordination. A Function with ATS Capability must accept/complete invalidations even when ATS is disabled, and clearing BME does not remove that duty.

Base 6.0 §10.1.1, Figures 10-4/10-5, pp.1474–1476; §§10.3–10.3.6, Figures 10-18–10-22, pp.1497–1503; §10.3.8, p.1505.

Why check Priv and Exe when Read is permitted?

Figure 10-14 uses R and W for allowed access types. Priv (Privileged Mode Access) identifies the privilege level to which those permissions apply; Exe (Execute Permitted) describes execution permission for the range. Privileged and non-privileged permissions are independent: one cannot be inferred from the other.

Teaching example: a PASID=21h Translation Request has effective Execute Requested and Privileged Mode Requested values of 0. A returned Exe=1 or Priv=1 conflicts with the applicable field rules. The Function may implement the specification's individual checks; if an implemented check fails, it must signal Unexpected Completion. These checks are optional, so the absence of an error alone does not establish that every field is valid.

For a valid Exe=1, the TA must support execute permissions, the Request must have an effective Execute Requested value of 1, and the returned R must be 1. Priv=1 requires TA privilege support and an effective Privileged Mode Requested value of 1. Interpret the effective value with the mode-specific PASID TLP Prefix or OHC-A1 and its enable conditions, not just the raw bit.

Global=1 permits the Function to cache a mapping shared across that Function's PASIDs; the Function may choose non-Global entries instead. A Function using Global must support Global Invalidate, and Global=1 is permitted only for a Translation Request with PASID. The platform defines what execution and privilege mean for the system.

Base 6.0 §10.2.3, Figure 10-14 and Table 10-3, pp.1485–1486; §§10.2.3.6–10.2.3.8, pp.1489–1491.

Why invalidate when the translated address is unchanged?

Recall that ATS Control AMAE=0 in the earlier example, so it did not use ATS Memory Attributes (AMA). Consider a separate teaching scenario: the Requester and TA support and enable AMA, and the ATC caches a page's translation and AMA. The platform changes that page's AMA while its translated address remains the same.

AMA values are associated with the Completer and have implementation-specific meaning; the Requester, ATC, and TA treat those values as opaque. An AMA-capable ATC may cache them with the translation. When an AMA for a page that could be cached changes, software must issue ATS Invalidation covering that page so the ATC does not use the stale value. Checking only whether the translated address changed is insufficient.

In Figure 10-17, a Translation Completion may provide AMA, and the Endpoint may later carry it with Memory Read/Write using a TPH TLP Prefix, potentially avoiding a TA lookup. This is an implementation example: the Completer's behavior for an AMA value and how the TA detects and enables AMA support depend on implementation or platform documentation. When AMA is not enabled in both Requester and TA, the default value is 000b.

TPH

TLP Processing Hints

Base 6.0 §§10.1.4 and 10.2.3.9, Figure 10-17, pp.1478 and 1493–1495; ATS Capability/Control: §10.5.1, pp.1513–1516.

Which PASIDs lose cached entries for a given range?

Figure 10-20 identifies an untranslated address range; PASID presence and Global Invalidate determine its scope. Teaching assumptions: the function is in D0, PASID Enable is set, Global Invalidate is supported, the range includes 40001000h, and PASIDs 21h and 22h are valid.

On a phone, scroll the table sideways to see all columns.

If Global Invalidate is unsupported, the ATC ignores that bit in a request with PASID and applies §10.3.8 to in-range entries requested with the specified PASID. The bit is Reserved when the request has no PASID. An Invalidate Completion is still required if no entries match or PASID Enable is clear; an out-of-range PASID may be reported as UR.

Outstanding reads, posted writes, and completion requirements still apply. Base 6.0 §10.3.1 and §10.3.8, Figure 10-20, pp.1498 and 1505.

Can the cache be invalidated without a message?

Yes. Section 10.3.7 lists implicit invalidation events, which do not send an explicit Invalidate Completion Message.

On a phone, scroll the table sideways to see all columns.

Stopping PASID 21h and re-enabling ATS can affect the same cache entry, but their scopes differ. No observed completion does not establish that an entry remains valid. PASID stop and reuse also require the coordination in §6.20.1. Base 6.0 §10.3.7, p.1504.

What if an old translation response and invalidation cross?

Teaching scenario: An Endpoint has an outstanding Translation Request covering 40001000h; the platform sends an overlapping Invalidate Request before its response arrives. They may use different TCs, so Link-level ordering does not establish their relative order.

1. Per §10.3.6 the ATC checks outstanding Translation Request ranges against arriving invalidations and marks an overlapping request invalid.
2. The corresponding result must be discarded as required so an old mapping does not remain after invalidation. If the response arrives before Invalidate Completion is sent, an implementation may temporarily use it, provided the new-request, outstanding-read, and posted-write conditions of §10.3.3 are met.
3. After the applicable work meets completion conditions, send Invalidate Completion. The platform considers the invalidation complete only after collecting all required responses.

Receipt of a translation response and completion of the invalidation exchange are distinct events. When Shadow Functions are enabled, §10.3.3 includes relevant requests from the Function and its Shadows; one invalidation may target either, subject to the specified Posted Write push conditions. Base 6.0 §10.3.3 and §10.3.6, pp.1501 and 1503–1504.

Does Invalidate Queue Depth=4 mean only four requests can be accepted?

These mechanisms describe different things. Invalidate Queue Depth is the number the function can buffer before applying Link backpressure; 00000b means invalidate flow control is not necessary for a non-VF Function; Table 10-10 interprets non-VF zero as accepting 32 requests, while a VF reads zero and uses its associated PF value. Input, output, or hybrid queuing is an implementation choice.

Section 10.3.4 forbids making acceptance of a new Invalidate Request depend on transmitting an earlier Invalidate Completion: both are Posted transactions and such a dependency can deadlock. Its implementation note describes up to 32 outstanding invalidations from one TA to an ATC; this does not require a 32-entry input queue.

With SR-IOV, VFs associated with a PF share an Invalidation Request queue in the PF. For a nonzero PF Invalidate Queue Depth, the TA must keep the total outstanding targeting that shared queue within that value. If the earlier assumed value 4 is used in such a shared PF/VF configuration, count the relevant functions together.

SR-IOV

Single Root I/O Virtualization

Invalidate Completions may coalesce multiple ITag Vector bits when the specified conditions, including the same TC and CC, hold. All fragments must have identical Requester ID, CC, and ITag Vector; the TA still collects the required replies for each ITag. Base 6.0 §10.3.2 and §10.3.4–§10.3.5, pp.1500–1503.

TC

Traffic Class

Page service returns to ATS

After invalidation completes, the device queries 40001000h again and receives R=W=0. For this continuation, platform page management separately confirms that both 40001000h and 40002000h are non-resident and the Function has legitimate Read work. Page non-residence is an additional teaching assumption; R=W=0 alone does not establish its cause.

Under §10.4 request both pages using PASID 21h, R=1, W=0 and PRG (Page Request Group) Index 005h. Only the second Message has Last=1. PRG Response PASID Required=1 in this case, so the successful response must contain the same PASID.

Page Request uses Code 04h, Route to Root Complex; PRG Response uses Code 05h, Route by ID. Both use TC0. Select Non-Flit Figures 10-23/10-27 or Flit Figures 10-24/10-28 for their page, index and response fields rather than treating them as Memory Completions.

Table 10-8 Success (0000b) means all group pages were made resident. It supplies no physical frame address. The case then issues fresh ATS; assume its new valid 4 KiB mapping has base A0000000h. Offset 234h now gives A0000234h, obtained from the new Translation Completion rather than the PRG Response.

There is no partial-success format for a group. Invalid Request (0001b) means an address/permission cannot be satisfied and retry cannot succeed without a mapping change. Response Failure (1111b) terminates the interface and needs recovery under its rules. Different PRGs have no completion-order guarantee.

Base 6.0 §§10.4–10.4.2.2, Figures 10-23/10-24 and 10-27/10-28, Tables 10-6–10-8, pp.1505–1513.

Reserve all messages before starting a group

Allocation 3 permits three outstanding Page Requests, not three groups. Section 10.5.2.5 requires availability for the whole PRG before its first Request. Distinguish issued messages from reserved messages not yet transmitted:

One group response returns two message allocations and releases the PRG Index. With only one free allocation, do not send the first half of a two-page group while waiting for more. These are not the Link Flow Control Credits in Chapter 17.

Allocation is shared by all PASIDs of the Function. For SR-IOV, a PF/VF Page Request Interface may be shared while packets preserve the actual requesting Function's RID. VF ATS Enable can be controlled independently of the PF. Continue the scope reasoning in Chapter 26.

Base 6.0 §10.4, p.1506; §10.5.1, p.1513; §10.5.2, p.1516; §10.5.2.5 Outstanding Page Request Allocation (Offset 0Ch), p.1520.

What happens to outstanding requests when PASID 21h stops?

Teaching scenario: Reuse PASID 21h and the earlier two-page PRG, but both requests are sent, the final one has L=1, and its PRG Response has not yet arrived. Stopping this PASID does not mean the entire Page Request Interface has stopped.

Section 10.4.1.2 provides two paths. Both stop queuing new requests for 21h and finish any incomplete multi-page group, including its final L=1 request.

On a phone, scroll the table sideways to see all columns.

The Stop Marker marks the PASID boundary. Once the Host receives it, old Page Requests for that PASID have been delivered, and subsequent requests with that PASID belong to its new use. The Marker has no response, PRG Index, or Page Request Allocation charge. Sending it does not immediately return old requests' credits.

Other outstanding transactions and platform/device coordination also matter when stopping or reusing a PASID. Base 6.0 §10.4.1.2–§10.4.1.2.1 and §10.5.2.5, pp.1509–1510 and 1520.

How can a trace distinguish a Stop Marker?

Identify the Page Request Message, then consult Figures 10-25 and 10-26. A Stop Marker has L=1, W=0, R=0, Marker Type 00000b, TC0, and Relaxed Ordering=0. Non-Flit Mode uses a PASID Prefix; Flit Mode uses OHC-A1 with PASID.

These fields mark a stop boundary, not a request to load a page without read or write access. The untranslated address and upper PRG Index bits are Reserved; do not interpret them as a page address or group number.

Behavior is undefined, for example, when the Host has no matching PASID stop request or an incomplete group for that PASID has not sent its final L=1 request. Base 6.0 §10.4.1.2.1, Figures 10-25 and 10-26, pp.1509–1510.

What should be checked in a PRG Response?

Use Figure 10-27 or 10-28 for the mode and destination Function, then match the PRG Index to an outstanding group. When a Page Request has a PASID, Status.PRG Response PASID Required determines whether the Response must carry it; incompatible formats can lead to undefined Function behavior.

If one request in a PRG carries a PASID, all requests in that PRG must carry the same PASID; inconsistent values have undefined behavior. A PASID Page Request with Execute Requested set must also set R; W=1 requires explicit write permission because the Host may mark the page dirty. When PRG Response PASID Required=0, Responses do not carry PASID and the Function shares PRG Index values across PASIDs.

Table 10-8 defines Response Code 0000b as group Success, 0001b as Invalid Request, unused 0010b–1110b values as treated like Response Failure, and 1111b as Response Failure. Failure terminates normal page-request service; later PRG Responses are ignored until re-enablement.

An otherwise error-free response with an unexpected PRG Index sets Unexpected Page Request Group Index (UPRGI). Success still requires a new ATS lookup to obtain a translation. Base 6.0 §10.4.1.1, §10.4.2–§10.4.2.2, Table 10-8, pp.1508 and 1511–1513.

How do Enable and Stopped describe stopping the interface?

In an SR-IOV arrangement using one PF Page Request Interface shared with its VFs, the PF implements the capability and its VFs must not. Each Page Request still carries the actual PF or VF Requester ID, and the corresponding PRG Response targets that Function. Base 6.0 §10.5.2, p.1516.

This concerns the whole interface, not the Stop Marker for one PASID. Locate the structure in Figure 10-33 and read Control and Status in Figures 10-35 and 10-36 and Tables 10-14 and 10-15. In the Header (Figure 10-34), ID is 0013h, Version is 1, and Next Capability Offset in bits 31:20 is relative to Configuration Space.

On a phone, scroll the table sideways to see all columns.

Writing Reset=1 clears internal credit and pending-request state only when Enable is clear or cleared in the same write. With Enable still set it initiates no action. Re-enabling before successful stop has indeterminate results.

Status.Response Failure and UPRGI are bits 0 and 1, respectively, and are RW1C (write one to clear). Re-enabling the interface also clears these flags. When PF and VFs share an interface, these events from associated Functions are recorded in the PF.

Outstanding Page Request Capacity is the read-only limit; Allocation is set before enabling, must not change while Enable=1, and must not exceed Capacity. With Shadow Functions enabled, Allocation is shared by the main Function and enabled Shadows; stopping a PASID does not immediately return its allocated credits.

Base 6.0 §10.5.2.1–§10.5.2.5, Figures 10-33–10-36 and Tables 10-13–10-15, pp.1517–1520.

Build the next reading route from the packet type

Confirm RID, PASID, mode and platform service, then each Support/Enable. Use Table 10-1 for AT, match Translation Completions to their original Requests, decode size and permissions, and only then form data access. Mapping changes add range, ITag Vector, CC and in-flight Transaction checks; Page Requests add PRG, Last, PASID, allocation and Response Code checks.

Stopping/reusing PASID also needs §6.20.1 and Chapter 10's rules for old Requests, Posted Writes, ATC entries and Page Requests. Reset and ATS Enable changing from 0 to 1 cause implicit invalidation too; a prior snapshot is not a current cache inventory.

Edition and source route

PCI Express Base Specification Revision 6.0 (6.0-1.0-PUB) supplies the rules. Printed and PDF-viewer pages match. All topology, fields, mappings and traces are author-created; no hardware or platform page service was operated. No external website supplies technical claims.