Intel ITANIUM ARCHITECTURE - SOFTWARE DEVELOPERS VOLUME 3 REV 2.3, Manual

Page: 864 / 1898

2:616 Volume 2, Part 2: I/O Architecture
The mf.a instruction on the other hand ensures that all prior data memory references
made by the processor issuing the mf.a have been “accepted” by the external platform.
However by itself the mf.a does not guarantee that all cache coherent agents have
observed all prior memory operations. For instance, an uncacheable store to a chipset
register may have completed on the system bus, however, that does not entail that all
prior cacheable transactions (from the processor issuing the store) have been observed
by all other processors in the coherence domain.
If software needs to ensure that all prior memory operations have been accepted by the
platform
and have been observed by all cache coherent agents, both an
mf.a
and an
mf
instruction must be issued. The
mf.a
must be issued first, and the
mf
must be issued
second. For more details on memory ordering between cache coherent agents please
refer to
Chapter 2, “MP Coherence and Synchronization.”
Typically
mf.a
is used to configure a system’s I/O space, e.g. to setup chipset registers
that affect all subsequent memory operations. Specifically, the mf.a instruction
restrains further data accesses from initiating on the external platform interface until:
1. All previous sequential (i.e. non write-coalescing uncacheable) loads have been
returned data, and
2. All previous stores have been “accepted” by the platform. Typically acceptance is
indicated by a bus-specific signals/phase, e.g. completion of response phase on
the system bus.
Architecturally, the definition of “acceptance” is platform dependent. The next section
discusses the usage of the
mf.a
instruction in the context of the I/O port space.
11.2 I/O Port Space
IA-32 processors support two I/O models: memory mapped I/O and the 64KB I/O port
space. To support IA-32 platforms, the Itanium architecture allows operating systems
to map the 64KB I/O port space into the 64-bit virtual address space. This allows
Itanium architecture-based operating systems to see all I/O devices as a single unified
memory mapped I/O model, and permits “normal” Itanium load and store instructions
as well as IA-32 IN and OUT instructions to directly access the I/O port space.
As described in Section 10.7, “I/O Port Space Model” on page 2:267 , Itanium
architecture-based operating systems can map the physical 64KB I/O port space into a
spread-out 64MB block of virtual address space. The virtual base address of the I/O
port space (IOBase) is maintained by the operating system in kernel register KR0.
When the processor issues Itanium load and stores accesses to the I/O port space, a
port’s virtual address is computed as:
port_virtual_address = IOBase | (port{15:2}<<12) | port{11:0}
For Itanium loads and stores, this address computation places four 1-byte ports on
each 4KB page and expands the space to 64MB, with the ports being at a relative offset
specified by port{11:0} within each 4KB virtual page. When executing an IA-32 IN or
OUT instruction a processor based on the Itanium architecture automatically converts
the IA-32 address to the appropriate expanded I/O port space address.