Re: [RFC PATCH 1/2] PCI/doe: Initial support PCI Data Object Exchange

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

On Thu, 18 Mar 2021 14:25:29 +0000
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:

> On Wed, 17 Mar 2021 18:30:26 -0700
> Dan Williams <dan.j.williams@intel.com> 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@avery-design.com> wrote:  
> > >
> > > Please address and clarify 2 queries below...
> > >
> > >    
> > > > On Mar 16, 2021, at 2:14 PM, Dan Williams <dan.j.williams@intel.com> wrote:
> > > >
> > > > On Tue, Mar 16, 2021 at 9:31 AM Jonathan Cameron
> > > > <Jonathan.Cameron@huawei.com> wrote:    
> > > >>
> > > >> On Mon, 15 Mar 2021 12:45:49 -0700
> > > >> Dan Williams <dan.j.williams@intel.com> 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@huawei.com> 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.

Thanks,

Jonathan