> On Jun 17, 2021, at 1:12 PM, Jonathan Cameron <jonathan.cameron@xxxxxxxxxx> wrote: > > On Thu, 18 Mar 2021 14:25:29 +0000 > Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote: > >> On Wed, 17 Mar 2021 18:30:26 -0700 >> Dan Williams <dan.j.williams@xxxxxxxxx> wrote: >> >>> Btw your mailer does something odd with the "In-Reply-To:" field, I >>> need to fix it up manually to include your address. >>> >>> On Tue, Mar 16, 2021 at 4:28 PM Chris Browy <cbrowy@xxxxxxxxxxxxxxxx> wrote: >>>> >>>> Please address and clarify 2 queries below... >>>> >>>> >>>>> On Mar 16, 2021, at 2:14 PM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: >>>>> >>>>> On Tue, Mar 16, 2021 at 9:31 AM Jonathan Cameron >>>>> <Jonathan.Cameron@xxxxxxxxxx> wrote: >>>>>> >>>>>> On Mon, 15 Mar 2021 12:45:49 -0700 >>>>>> Dan Williams <dan.j.williams@xxxxxxxxx> wrote: >>>>>> >>>>>>> Hey Jonathan, happy to see this, some comments below... >>>>>> >>>>>> Hi Dan, >>>>>> >>>>>> Thanks for taking a look! >>>>>> >>>>>>> >>>>>>> On Wed, Mar 10, 2021 at 10:08 AM Jonathan Cameron >>>>>>> <Jonathan.Cameron@xxxxxxxxxx> wrote: >>>>>>>> >>>>>>>> Introduced in an ECN to the PCI 5.0, DOE provides a config space >>>>>>>> based mailbox with standard protocol discovery. Each mailbox >>>>>>>> is accessed through a DOE PCIE Extended Capability. >>>>>>>> >>>>>>>> A device may have 1 or more DOE mailboxes, each of which is allowed >>>>>>>> to support any number of protocols (some DOE protocols >>>>>>>> specifications apply additional restrictions). A given protocol >>>>>>>> may be supported on more than one DOE mailbox on a given function. >>>>>>> >>>>>>> Are all those protocol instances shared? >>>>>>> I'm trying to mental model >>>>>>> whether, for example, an auxiliary driver instance could be loaded per >>>>>>> DOE mailbox, or if there would need to be coordination of a given >>>>>>> protocol no matter how many DOE mailboxes on that device implemented >>>>>>> that protocol. >>>>>> >>>>>> Just to check I've understood corectly, you mean multiple instances of same >>>>>> protocol across different DOE mailboxes on a given device? >>>>>> >>>>> >>>>> Right. >>>> >>>> Could you confirm this case for clarity? A CXL device may have multiple VF/PF. >>>> For example, PF=0 could have one or more DOE instances for CDAT protocol. >>>> The driver will scan PF=0 for all DOE instances and finding one or more of CDAT >>>> protocol will combine/manage them. I had not considered multiple CDAT tables >>>> for single PF. For CXL devices with multiple PF’s the same process would be >>>> carried out on PF=1-N. >>> >>> This patch has nothing to do with CXL. This is a general discussion of >>> how a PCIE device implements a DOE mailbox or set of mailboxes. The >>> DOE definition is PF-only afaics from the DOE specification. >>> >>> The CXL specification only says that a device can implement a CDAT per >>> DOE capability instance, so the CXL spec does not limit the number of >>> DOE instances to 1, but I can't think of a practical reason to support >>> more than one. >>> >>> [..] >>>>>>> https://cfp.osfc.io/media/osfc2020/submissions/ECQ88N/resources/An_open_source_SPDM_implementation_for_secure_devi_kmIgAQe.pdf >>>>>> >>>>>> Nice! Looking at CMA / IDE emulation was on my todo list and that looks like >>>>>> it might make that job a lot easier. >>>> >>>> Would it be useful to integrate the openspdm’s SpdmResponderEmu.c onto the QEMU’s CXL Type3 Device’s >>>> DOE backend for CMA/IDE testing? Doesn’t look hard to do. >>> >>> Yes, I do think it would be useful. >> >> Agreed. Very useful indeed. >> >> Jonathan >> > > Hi Chris, > > Just wondering if this qemu/openspdm integration was something your team have > had time to look at? I'd like to ideally get a second DOE usecase > implemented on the Linux side to prove out the implementation. > > If it's fallen off your near term todo list I might see if I can hack > something together in the meantime. We have been working on this. The plan was 1) implement modified version of openspdm requester running as QEMU app to pass DOE via CXL driver IOCTL’s to do DOE (DONE) 2) enhance cxl_type3.c to call openspdm responder to implement device side SPDM (NOT DONE) 3) enhance the Avery CXL Type 3 device SystemVerilog model to call opensldm responder to implement device side SPDM (DONE) Currently we run 1) and 3) using our QEMU co-sim environment. Huai-Cheng can probably finish 2) next week so we can run entirely in QEMU stand-alone environment. > > Thanks, > > Jonathan
