linux-kernel - RE: [PATCH v3 3/5] fpga: dfl: fix VF creation in OFS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DM6PR11MB3819DB26C00B07D058B7A65C85029@DM6PR11MB3819.namprd11.prod.outlook.com>
Date:   Tue, 1 Mar 2022 07:13:26 +0000
From:   "Wu, Hao" <hao.wu@...el.com>
To:     "Zhang, Tianfei" <tianfei.zhang@...el.com>,
        "trix@...hat.com" <trix@...hat.com>,
        "mdf@...nel.org" <mdf@...nel.org>,
        "Xu, Yilun" <yilun.xu@...el.com>,
        "linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "corbet@....net" <corbet@....net>,
        Matthew Gerlach <matthew.gerlach@...ux.intel.com>
Subject: RE: [PATCH v3 3/5] fpga: dfl: fix VF creation in OFS

> Subject: [PATCH v3 3/5] fpga: dfl: fix VF creation in OFS

Why this is a fix? 

> 
> In OFS legacy model, there is only 1 Port device related to
> 1 VF, the flag DFL_FEAT_PORT_CONNECTED_AFU will take notes for
> this model. 

What is OFS legacy model? And what is legacy model? They are
the same or not? It's quite confusing.

> In legacy model, it need to check the released port
> number match VF device number or not. But in "Multiple VFs per
> PR slot" model, the Port device would not connected to AFU/PR
> slot, so we don't need to release the Port device before creating
> the VFs.

I think the major difference here is not that PORT has AFU or not, but
If PORT needs to be turned into VFs. Would it be better to be decided
by FME registers controlling the access to PORT?

If we consider following same flow for enable SRIOV to reuse existing
tools, then we need to add FME flags to indicate user (and dfl-pci), 
no need to assign/release port for SRIOV enabling.

Hao

> 
> Signed-off-by: Matthew Gerlach <matthew.gerlach@...ux.intel.com>
> Signed-off-by: Tianfei zhang <tianfei.zhang@...el.com>
> ---
>  drivers/fpga/dfl.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> index 5872031c2e9f..fd04ef5c8b03 100644
> --- a/drivers/fpga/dfl.c
> +++ b/drivers/fpga/dfl.c
> @@ -1702,11 +1702,13 @@ int dfl_fpga_cdev_config_ports_vf(struct
> dfl_fpga_cdev *cdev, int num_vfs)
> 
>  	mutex_lock(&cdev->lock);
>  	/*
> -	 * 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.
> +	 * In the OFS legacy model, it can't turn multiple ports into 1 VF
> +	 * device, because only 1 port conneced to 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 ((cdev->features & DFL_FEAT_PORT_CONNECTED_AFU) &&
> +	    cdev->released_port_num != num_vfs) {
>  		ret = -EINVAL;
>  		goto done;
>  	}
> --
> 2.26.2