linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Zhang, Tianfei" <tianfei.zhang@intel.com>
To: Tom Rix <trix@redhat.com>, "Wu, Hao" <hao.wu@intel.com>,
	"mdf@kernel.org" <mdf@kernel.org>,
	"Xu, Yilun" <yilun.xu@intel.com>,
	"linux-fpga@vger.kernel.org" <linux-fpga@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "corbet@lwn.net" <corbet@lwn.net>,
	Matthew Gerlach <matthew.gerlach@linux.intel.com>
Subject: RE: [PATCH v1 4/7] fpga: dfl: fix VF creation when ports have no local BAR space
Date: Fri, 18 Feb 2022 08:14:04 +0000	[thread overview]
Message-ID: <BN9PR11MB54830E0D185101B6B1517113E3379@BN9PR11MB5483.namprd11.prod.outlook.com> (raw)
In-Reply-To: <c527e9c7-4588-463b-8a6b-3db68d003d7a@redhat.com>



> -----Original Message-----
> From: Tom Rix <trix@redhat.com>
> Sent: Tuesday, February 15, 2022 11:51 PM
> To: Zhang, Tianfei <tianfei.zhang@intel.com>; Wu, Hao <hao.wu@intel.com>;
> mdf@kernel.org; Xu, Yilun <yilun.xu@intel.com>; linux-fpga@vger.kernel.org;
> linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: corbet@lwn.net; Matthew Gerlach <matthew.gerlach@linux.intel.com>
> Subject: Re: [PATCH v1 4/7] fpga: dfl: fix VF creation when ports have no local
> BAR space
> 
> 
> On 2/14/22 3:26 AM, Tianfei zhang wrote:
> > From: Matthew Gerlach <matthew.gerlach@linux.intel.com>
> >
> > When a port is not connected to the same PCIe endpoint as the FME, the
> > port does not need to be released before being virtualized.  Fix VF
> > creation code to handle this new use
> Similar, how does this fit in with iofs, this looks like it would not be valid for the
> existing cards

IOFS introducing multiple methods for PR and AFU access.
1. Legacy Model.
2. Micro-Personas in AFU.
3. Multiple VFs per PR slot.

For 1 and 2 model, there are 1:1 mapping between Port device and PR slot (or entire AFU). In virtualization,
it should release the Port device firstly and then assign to VM. In this models, the DFL driver will track  that
the number of port devices has released (cdev->released_port_num in dfl_fpga_cdev_config_ports_vf() function)
are equal with the numbers of SRIOV or not. But in model 3, it has multiple VFs per PR slot, and assign the VF to VM 
without release the port device, so the tracking mechanism of cdev->released_port_num is not workable on new
model. This patch want to handle this new model during VF creation.

> > case.
> >
> > Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
> > Signed-off-by: Tianfei Zhang <tianfei.zhang@intel.com>
> > ---
> >   drivers/fpga/dfl.c | 11 +++++++++--
> >   1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c index
> > 26f8cf890700..cfc539a656f0 100644
> > --- a/drivers/fpga/dfl.c
> > +++ b/drivers/fpga/dfl.c
> > @@ -1705,15 +1705,22 @@
> EXPORT_SYMBOL_GPL(dfl_fpga_cdev_config_ports_pf);
> >   int dfl_fpga_cdev_config_ports_vf(struct dfl_fpga_cdev *cdev, int num_vfs)
> >   {
> >   	struct dfl_feature_platform_data *pdata;
> > -	int ret = 0;
> > +	int ret = 0, port_count = 0;
> >
> >   	mutex_lock(&cdev->lock);
> > +
> > +	list_for_each_entry(pdata, &cdev->port_dev_list, node) {
> > +		if (pdata->dev)
> 
> This looks wrong,
> 
> pdata->dev is dereferenced below, if there is a case were (!pdata->dev)
> here there would be crash later.
> 
> > +			continue;
> > +		port_count++;
> 
> how does this work when only some of the ports are handled in the new way ?

This code want to handle the " Multiple VFs per PR slot" model as I mentioned above.
In new model, the port_count want to count that how many port devices have released.
This code looks not good readability, I try to re-write it.

> 
> Tom
> 
> > +	}
> > +
> >   	/*
> >   	 * can't turn multiple ports into 1 VF device, only 1 port for 1 VF
> >   	 * device, so if released port number doesn't match VF device number,
> >   	 * then reject the request with -EINVAL error code.
> >   	 */
> > -	if (cdev->released_port_num != num_vfs) {
> > +	if (port_count && cdev->released_port_num != num_vfs) {
> >   		ret = -EINVAL;
> >   		goto done;
> >   	}


  reply	other threads:[~2022-02-18  8:14 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-14 11:26 [PATCH v1 0/7] Add Intel OFS support for DFL driver Tianfei zhang
2022-02-14 11:26 ` [PATCH v1 1/7] Documentation: fpga: dfl: add description of IOFS Tianfei zhang
2022-02-14 12:18   ` Akira Yokosawa
2022-02-14 17:56     ` Randy Dunlap
2022-02-14 23:27       ` Zhang, Tianfei
2022-02-15 14:32   ` Tom Rix
2022-02-16  3:34   ` Wu, Hao
2022-02-21  7:39     ` Zhang, Tianfei
2022-02-14 11:26 ` [PATCH v1 2/7] fpga: dfl: check feature type before parse irq info Tianfei zhang
2022-02-15 14:49   ` Tom Rix
2022-02-17  2:38     ` Xu Yilun
2022-02-21  7:54       ` Zhang, Tianfei
2022-02-18  6:53     ` Zhang, Tianfei
2022-02-18 14:29       ` Tom Rix
2022-02-21 12:05         ` Zhang, Tianfei
2022-02-16  3:35   ` Wu, Hao
2022-02-21  7:41     ` Zhang, Tianfei
2022-02-14 11:26 ` [PATCH v1 3/7] fpga: dfl: Allow for ports with no local bar space Tianfei zhang
2022-02-15 15:05   ` Tom Rix
2022-02-18  7:31     ` Zhang, Tianfei
2022-02-18 14:49       ` Tom Rix
2022-02-21 17:22         ` matthew.gerlach
2022-02-21 17:51           ` Tom Rix
2022-02-22  9:07             ` Zhang, Tianfei
2022-02-16  3:38   ` Wu, Hao
2022-02-21  7:48     ` Zhang, Tianfei
2022-02-14 11:26 ` [PATCH v1 4/7] fpga: dfl: fix VF creation when ports have no local BAR space Tianfei zhang
2022-02-15 15:50   ` Tom Rix
2022-02-18  8:14     ` Zhang, Tianfei [this message]
2022-02-18 14:55       ` Tom Rix
2022-02-14 11:26 ` [PATCH v1 5/7] drivers: fpga: dfl: handle empty port list Tianfei zhang
2022-02-15 15:55   ` Tom Rix
2022-02-18  8:24     ` Zhang, Tianfei
2022-02-14 11:26 ` [PATCH v1 6/7] fpga: dfl: Handle dfl's starting with AFU Tianfei zhang
2022-02-15 16:09   ` Tom Rix
2022-02-14 11:26 ` [PATCH v1 7/7] fpga: dfl: pci: Add generic OFS PCI PID Tianfei zhang
2022-02-15 16:16   ` Tom Rix
2022-02-18  9:03     ` Zhang, Tianfei
2022-02-18 15:27       ` Tom Rix
2022-02-21 17:50         ` matthew.gerlach
2022-02-21 18:09           ` Tom Rix
2022-02-22  3:11             ` Zhang, Tianfei
2022-02-22 16:11               ` Tom Rix
2022-02-23  1:48                 ` Zhang, Tianfei
2022-02-24 17:54                 ` matthew.gerlach
2022-02-28 10:57                   ` Wu, Hao
2022-03-01  0:25                     ` matthew.gerlach

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=BN9PR11MB54830E0D185101B6B1517113E3379@BN9PR11MB5483.namprd11.prod.outlook.com \
    --to=tianfei.zhang@intel.com \
    --cc=corbet@lwn.net \
    --cc=hao.wu@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fpga@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew.gerlach@linux.intel.com \
    --cc=mdf@kernel.org \
    --cc=trix@redhat.com \
    --cc=yilun.xu@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).