linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Browy <cbrowy@avery-design.com>
To: Jonathan Cameron <jonathan.cameron@huawei.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	linux-cxl@vger.kernel.org, Linux PCI <linux-pci@vger.kernel.org>,
	Ben Widawsky <ben.widawsky@intel.com>,
	Bjorn Helgaas <helgaas@kernel.org>,
	Linux ACPI <linux-acpi@vger.kernel.org>,
	"Schofield, Alison" <alison.schofield@intel.com>,
	Vishal L Verma <vishal.l.verma@intel.com>,
	"Weiny, Ira" <ira.weiny@intel.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Linuxarm <linuxarm@huawei.com>, Fangjian <f.fangjian@huawei.com>
Subject: Re: [RFC PATCH 1/2] PCI/doe: Initial support PCI Data Object Exchange
Date: Thu, 17 Jun 2021 15:48:28 -0400	[thread overview]
Message-ID: <1BC68362-057C-4AB4-BC7C-731CFC3DBED7@avery-design.com> (raw)
In-Reply-To: <20210617181225.0000105b@Huawei.com>



> On Jun 17, 2021, at 1:12 PM, Jonathan Cameron <jonathan.cameron@huawei.com> wrote:
> 
> 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.

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


  reply	other threads:[~2021-06-17 20:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-10 18:03 [RFC PATCH 0/2] PCI Data Object Exchange support + CXL CDAT Jonathan Cameron
2021-03-10 18:03 ` [RFC PATCH 1/2] PCI/doe: Initial support PCI Data Object Exchange Jonathan Cameron
2021-03-15 19:45   ` Dan Williams
2021-03-16 16:29     ` Jonathan Cameron
2021-03-16 16:57       ` Jonathan Cameron
2021-03-16 18:14       ` Dan Williams
2021-03-16 23:26         ` Chris Browy
2021-03-18  1:30           ` Dan Williams
2021-03-18 14:25             ` Jonathan Cameron
2021-06-17 17:12               ` Jonathan Cameron
2021-06-17 19:48                 ` Chris Browy [this message]
2021-03-23 18:22         ` Jonathan Cameron
2021-03-23 18:57           ` Dan Williams
2021-03-10 18:03 ` [RFC PATCH 2/2] cxl/mem: Add CDAT table reading from DOE Jonathan Cameron
2021-03-10 18:14   ` Jonathan Cameron
2021-03-10 22:59     ` Chris Browy
2021-03-15 22:00     ` Dan Williams
2021-03-16 10:36       ` Jonathan Cameron
2021-03-17  1:42         ` Dan Williams
2021-03-17  1:55   ` Dan Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1BC68362-057C-4AB4-BC7C-731CFC3DBED7@avery-design.com \
    --to=cbrowy@avery-design.com \
    --cc=20210617181225.0000105b@Huawei.com \
    --cc=alison.schofield@intel.com \
    --cc=ben.widawsky@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=f.fangjian@huawei.com \
    --cc=helgaas@kernel.org \
    --cc=ira.weiny@intel.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=vishal.l.verma@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).