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]

 



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.




[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