Re: [RFC PATCH 1/1] server extension: PCIe requirements
Josh Scheid
On Wed, Jun 9, 2021 at 11:27 AM Mayuresh Chitale <mchitale@...> wrote: This patch adds requirements for PCIe support for the server extension
Is this an M-mode SW requirement or a HW requirement that these interrupts are delegatable (writeable) in HW? Why require the delegation by M-mode instead of allowing for M-mode to trap and pass down? Is this just a performance benefit? -* PCI-E Any particular baseline PCIe version and/or extensions? + Is there any guidance needed about the amount of total space available (below 4G), or that space needs to be allocated for each domain? I think that this is only necessary in the platform because of the current lack of an IOMMU requirement or standard. With an IOMMU, that component can be used to locate 32-bit BARS anywhere in the system address space. So at least keep in mind the requirement can be dropped at that time. This region may be configured as I/O region or as memory region. Is an SBI call needed to support S-mode configuration? What is the default expected to be if there is no SBI call or no call is made? IIRC, some older versions of some HCI standards (USB, SATA?) only had device support for 32-bit addresses. I mention this to check if the requirement is really just that non-prefetchable BARs need to be supported <4GB, or that it's also needed for other 32-bit BAR support. Thus it may need to support prefetchable BARs located <4GB. + While a standard IOMMU is further off, is the current opinion that the IOPMP is not in a position to be required or suggested as an implementation of the above requirement? If not, then it's hard to check for compliance. Is this mechanism expected to be M-mode SW controlled, or is it also expected to be controlled by S-mode (either directly or via SBI)? + While TBD, one question interesting to me is whether or not it matters if the PCI RC implements it's own INTx to MSI bridge, or if an AIA APLIC is required for that. + Is it implicit here if this mechanism is provided to M-mode SW only, or also to S-mode? +* If the host bridge/root port receives a TLP which does not have `NoSnoop` bit I read this as primarily stating that inbound NoSnoop controls the "coherent" access attribute. But why this instead of focusing on control of the "cacheable" vs "non-cacheable" attribute? With the latter, it seems more apparent how harts would then manages coherency: by controlling accesses to use the same "cacheable" attribute. + Have we considered the option of requiring EPs to be behind virtual integrated RPs, instead of being RCiEPs? This seems to bypass some of the unique limitations of RCiEPs, including the RCEC. Do we need to ban or allow for impl-spec address mapping capabilities between PCI and system addresses? Do we need say anything about peer-to-peer support, or requirements if a system enables it? Including ACS? Should the system mtimer counter also be the source for PCIe PTP? -Josh
|
|