1. Tech-Unixplatformspec
  2. Topics

PCIe requirements: Memory vs I/O

Greg Favor
 

Thanks.


On Tue, Jun 15, 2021 at 6:00 PM Josh Scheid <jscheid@...> wrote:
On Tue, Jun 15, 2021 at 5:43 PM Josh Scheid via lists.riscv.org <jscheid=ventanamicro.com@...> wrote:

I can and will do that.  The point of raising this here is to explicitly confirm that the platform intent is to enable Memory PMA within, say, PCIe-managed regions.  With that confirmation now effectively clear we can push on the priv spec.



-Josh
Josh Scheid
 

On Tue, Jun 15, 2021 at 5:43 PM Josh Scheid via lists.riscv.org <jscheid=ventanamicro.com@...> wrote:

I can and will do that.  The point of raising this here is to explicitly confirm that the platform intent is to enable Memory PMA within, say, PCIe-managed regions.  With that confirmation now effectively clear we can push on the priv spec.



-Josh
Josh Scheid
 

On Tue, Jun 15, 2021 at 9:44 AM Greg Favor <gfavor@...> wrote:
This sentence is fraught with use of a few ill-defined terms, e.g. "regular main memory" and "device scratchpad RAMs" - which for now maybe isn't worth trying to "fix".  I would suggest making a PR on the Priv spec with a proposed rewording.  For example (with a goal of not totally replacing the sentence):

Memory regions that do not fit into regular main memory, for example, device-related RAMs, may be categorized as main memory regions or I/O regions based on the desired attributes.


I can and will do that.  The point of raising this here is to explicitly confirm that the platform intent is to enable Memory PMA within, say, PCIe-managed regions.  With that confirmation now effectively clear we can push on the priv spec.

-Josh
Greg Favor
 

This sentence is fraught with use of a few ill-defined terms, e.g. "regular main memory" and "device scratchpad RAMs" - which for now maybe isn't worth trying to "fix".  I would suggest making a PR on the Priv spec with a proposed rewording.  For example (with a goal of not totally replacing the sentence):

Memory regions that do not fit into regular main memory, for example, device-related RAMs, may be categorized as main memory regions or I/O regions based on the desired attributes.

Greg






On Tue, Jun 15, 2021 at 9:11 AM Josh Scheid <jscheid@...> wrote:
On Mon, Jun 14, 2021 at 7:10 PM Greg Favor <gfavor@...> wrote:
On Mon, Jun 14, 2021 at 3:56 PM Josh Scheid <jscheid@...> wrote:
The proposal allows for prefetchable BARs to be programmed to support as I/O or Memory.  This seems to conflict with the priv spec that states:

"""
Memory regions that do not fit into regular main memory, for example, device scratchpad RAMs,
are categorized as I/O regions.
"""

This is for outbound traffic and, if one sets aside the word "I/O" in the proposed text saying "two I/O regions for mapping ..." (e.g. replacing "I/O" with "address"), then is there a conflict? 

The prefetchable BAR can be "mapped" by either a PMA "main memory" region or by a PMA "I/O" region.


The conflict is that statement in the priv. spec suggests that things like  "device scratchpad RAMs" like those that might be in PCIe land "are" I/O, in that they are not Memory.  Moving that priv spec statement to be illustrative and non-normative may be a solution.  Perhaps it's not really mean to be a restriction, but then a more obvious I/O example instead of a "device scratchpad RAM" would be better, as well as making it non-normative.

-Josh
Josh Scheid
 

On Mon, Jun 14, 2021 at 7:10 PM Greg Favor <gfavor@...> wrote:
On Mon, Jun 14, 2021 at 3:56 PM Josh Scheid <jscheid@...> wrote:
The proposal allows for prefetchable BARs to be programmed to support as I/O or Memory.  This seems to conflict with the priv spec that states:

"""
Memory regions that do not fit into regular main memory, for example, device scratchpad RAMs,
are categorized as I/O regions.
"""

This is for outbound traffic and, if one sets aside the word "I/O" in the proposed text saying "two I/O regions for mapping ..." (e.g. replacing "I/O" with "address"), then is there a conflict? 

The prefetchable BAR can be "mapped" by either a PMA "main memory" region or by a PMA "I/O" region.


The conflict is that statement in the priv. spec suggests that things like  "device scratchpad RAMs" like those that might be in PCIe land "are" I/O, in that they are not Memory.  Moving that priv spec statement to be illustrative and non-normative may be a solution.  Perhaps it's not really mean to be a restriction, but then a more obvious I/O example instead of a "device scratchpad RAM" would be better, as well as making it non-normative.

-Josh
Greg Favor
 

On Mon, Jun 14, 2021 at 3:56 PM Josh Scheid <jscheid@...> wrote:
The proposal allows for prefetchable BARs to be programmed to support as I/O or Memory.  This seems to conflict with the priv spec that states:

"""
Memory regions that do not fit into regular main memory, for example, device scratchpad RAMs,
are categorized as I/O regions.
"""

This is for outbound traffic and, if one sets aside the word "I/O" in the proposed text saying "two I/O regions for mapping ..." (e.g. replacing "I/O" with "address"), then is there a conflict? 

The prefetchable BAR can be "mapped" by either a PMA "main memory" region or by a PMA "I/O" region.

Greg
Josh Scheid
 

The proposal allows for prefetchable BARs to be programmed to support as I/O or Memory.  This seems to conflict with the priv spec that states:

"""
Memory regions that do not fit into regular main memory, for example, device scratchpad RAMs,
are categorized as I/O regions.
"""

I agree that it is useful to allow for Memory treatment of some address space in some PCIe devices.  So there should be an action to accommodate that by adjusting the wording in the priv spec.

-Josh

1 - 7 of 7