Lines Matching refs:in

17 to freeze a device that is causing errors in order to limit the possibility
20 There is thus, in HW, a table of PE states that contains a pair of "frozen"
24 When a PE is frozen, all stores in any direction are dropped and all loads
33 (IODA2).  Keep in mind that this is all per PHB (PCI host bridge).  Each PHB
43     For DMA, MSIs and inbound PCIe error messages, we have a table (in
44     memory but accessed in HW by the chip) that provides a direct
54     - For MSIs, we have two windows in the address space (one at the top of
56       address and MSI value, will result in one of the 2048 interrupts per
57       bridge being triggered.  There's a PE# in the interrupt controller
68     First what they have in common: they forward a configurable portion of
70     power of two in size.  The rest is different:
74       * Is limited to 4GB in size.
84 	ignores that however and will forward in that space if we try).
86       * It is divided into 256 segments of equal size.  A table in the chip
91     Now, this is the "main" window we use in Linux today (excluding
96     Ideally we would like to be able to have individual functions in PEs
98     scheme where individual function BARs can be "grouped" to fit in one or
103       * Must be at least 256MB in size.
118     for large BARs in 64-bit space:
135     - We cannot "group" segments in HW, so if a device ends up using more
139       you freeze a switch, it freezes all its children).  So we do it in
140       SW.  We lose a bit of effectiveness of EEH in that case, but that's
146     We would like to investigate using additional M64 windows in "single
156     support several Virtual Functions (VFs).  Registers in the PF's SR-IOV
159     When VFs are enabled, they appear in Configuration Space like normal
160     PCI devices, but the BARs in VF config space headers are unusual.  For
161     a non-VF device, software uses BARs in the config space header to
163     software uses VF BAR registers in the *PF* SR-IOV Capability to
164     discover sizes and assign addresses.  The BARs in the VF's config space
167     When a VF BAR in the PF SR-IOV Capability is programmed, it sets the
170     1MB VF BAR0, the address in that VF BAR sets the base of an 8MB region.
174     i.e., 1MB in this example.
176   There are several strategies for isolating VFs in PEs:
181     mapped to separate PEs in this window.  Each segment can be
194     flexibility.  A VF with multiple BARs would have to be in a "domain" of
205   more in the next two sections.  For a given VF BAR, we need to
225   total_VFs is less than 256, we have the situation in Figure 1.0, where
246   space doesn't need that much, as shown in Figure 1.1:
267   reserved in software; there are still only total_VFs VFs, and they only
268   respond to segments [0, total_VFs - 1].  There's nothing in hardware that
276 In IODA2, the MMIO address determines the PE#.  If the address is in an M32
278 to PE#s.  Similarly, if the address is in an unsegmented M64 window, we can
279 set the PE# for the window.  But if it's in a segmented M64 window, the
283 of the VF(n) BAR space in the VF BAR.  If the PCI core allocates the exact
292 Then each VF will be in its own PE.  The VF BARs (and therefore the PE#s)
293 are contiguous.  If VF0 is in PE(x), then VF(n) is in PE(x+n).  If we
297 segments to cover a VF BAR, and a VF will be in several PEs.  This is