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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux