public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: devel@edk2.groups.io, nikita.leshchenko@oracle.com
Cc: liran.alon@oracle.com, aaron.young@oracle.com,
	Jordan Justen <jordan.l.justen@intel.com>,
	Ard Biesheuvel <ard.biesheuvel@arm.com>
Subject: Re: [edk2-devel] [PATCH v4 12/13] OvmfPkg/MptScsiDxe: Report multiple targets
Date: Mon, 20 Apr 2020 20:31:51 +0200	[thread overview]
Message-ID: <aa46e55b-496a-282f-4454-954b2db7935d@redhat.com> (raw)
In-Reply-To: <20200414173813.7715-13-nikita.leshchenko@oracle.com>

On 04/14/20 19:38, Nikita Leshenko wrote:
> The controller supports up to 8 targets (Not reported by the
> controller, but based on the implementation of the virtual device),
> report them in GetNextTarget and GetNextTargetLun. The firmware will
> then try to communicate with them and create a block device for each
> one that responds.
> 
> Support for multiple LUNs will be implemented in another series.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
> Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
> Reviewed-by: Liran Alon <liran.alon@oracle.com>
> ---
>  OvmfPkg/MptScsiDxe/MptScsi.c      | 38 ++++++++++++++++++++++++-------
>  OvmfPkg/MptScsiDxe/MptScsiDxe.inf |  1 +
>  OvmfPkg/OvmfPkg.dec               |  4 ++++
>  3 files changed, 35 insertions(+), 8 deletions(-)
> 
> diff --git a/OvmfPkg/MptScsiDxe/MptScsi.c b/OvmfPkg/MptScsiDxe/MptScsi.c
> index fcdaa4c338a4..3ea08857df5d 100644
> --- a/OvmfPkg/MptScsiDxe/MptScsi.c
> +++ b/OvmfPkg/MptScsiDxe/MptScsi.c
> @@ -46,6 +46,7 @@ typedef struct {
>    EFI_PCI_IO_PROTOCOL             *PciIo;
>    UINT64                          OriginalPciAttributes;
>    UINT32                          StallPerPollUsec;
> +  UINT8                           MaxTarget;
>    MPT_SCSI_DMA_BUFFER             *Dma;
>    EFI_PHYSICAL_ADDRESS            DmaPhysical;
>    VOID                            *DmaMapping;
> @@ -159,6 +160,7 @@ MptScsiInit (
>    UINT32                         ReplyWord;
>  
>    Dev->StallPerPollUsec = PcdGet32 (PcdMptScsiStallPerPollUsec);
> +  Dev->MaxTarget = PcdGet8 (PcdMptScsiMaxTargetLimit);
>  
>    Status = MptScsiReset (Dev);
>    if (EFI_ERROR (Status)) {
> @@ -169,7 +171,7 @@ MptScsiInit (
>    ZeroMem (&Reply, sizeof (Reply));
>    Req.Data.WhoInit = MPT_IOC_WHOINIT_ROM_BIOS;
>    Req.Data.Function = MPT_MESSAGE_HDR_FUNCTION_IOC_INIT;
> -  Req.Data.MaxDevices = 1;
> +  Req.Data.MaxDevices = Dev->MaxTarget + 1;

(1) If Dev->MaxTarget is 255, then the RHS will evaluate to 256. But the
LHS can only fit a UINT8.

Can you introduce the PCD in the INF file under a [FixedPcd] section,
and add:

  STATIC_ASSERT (FixedPcdGet8 (...) < 255, "...");

to MptScsiInit()?

(I'm unsure (and I'm too tired to check) whether FixedPcdGet8() will
expand to an integer constant. If it doesn't, then STATIC_ASSERT() won't
work. In that case we should likely use a plain ASSERT().)

>    Req.Data.MaxBuses = 1;
>    Req.Data.ReplyFrameSize = sizeof (MPT_SCSI_IO_REPLY);
>  
> @@ -240,7 +242,7 @@ MptScsiPopulateRequest (
>      return EFI_UNSUPPORTED;
>    }
>  
> -  if (Target > 0 || Lun > 0 ||
> +  if (Target > Dev->MaxTarget || Lun > 0 ||
>        Packet->DataDirection > EFI_EXT_SCSI_DATA_DIRECTION_BIDIRECTIONAL ||
>        //
>        // Trying to receive, but destination pointer is NULL, or contradicting
> @@ -552,12 +554,22 @@ MptScsiGetNextTargetLun (
>    IN OUT UINT64                                     *Lun
>    )
>  {
> +  MPT_SCSI_DEV *Dev;
> +
> +  Dev = MPT_SCSI_FROM_PASS_THRU (This);
>    //
> -  // Currently support only target 0 LUN 0, so hardcode it
> +  // Currently support only LUN 0, so hardcode it
>    //
>    if (!IsTargetInitialized (*Target)) {
>      ZeroMem (*Target, TARGET_MAX_BYTES);
>      *Lun = 0;
> +  } else if (**Target < Dev->MaxTarget) {
> +    //
> +    // This device support 256 targets only, so it's enough to increment
> +    // the LSB of Target, as it will never overflow.
> +    //
> +    **Target += 1;
> +    *Lun = 0;
>    } else {
>      return EFI_NOT_FOUND;
>    }

(2) Please implement the EFI_INVALID_PARAMETER branch as well, as seen
in PvScsiGetNextTargetLun(). It's a check on input:

  if (**Target > Dev->MaxTarget || *Lun > 0) {
    return EFI_INVALID_PARAMETER;
  }

And then, as a consequence, the "*Lun = 0" assignment is no longer
necessary, near the target increment. (Until you implement multi-LUN.)

To confirm, (Target==MaxTarget) on input should return EFI_NOT_FOUND,
while (Target>MaxTarget) on input should return EFI_INVALID_PARAMETER.

> @@ -573,11 +585,17 @@ MptScsiGetNextTarget (
>    IN OUT UINT8                                     **Target
>    )
>  {
> -  //
> -  // Currently support only target 0 LUN 0, so hardcode it
> -  //
> +  MPT_SCSI_DEV *Dev;
> +
> +  Dev = MPT_SCSI_FROM_PASS_THRU (This);
>    if (!IsTargetInitialized (*Target)) {
>      ZeroMem (*Target, TARGET_MAX_BYTES);
> +  } else if (**Target < Dev->MaxTarget) {
> +    //
> +    // This device support 256 targets only, so it's enough to increment
> +    // the LSB of Target, as it will never overflow.
> +    //
> +    **Target += 1;
>    } else {
>      return EFI_NOT_FOUND;
>    }

(3) Same as (2).

Hmmm. Maybe I should have pointed these out under patch#6
("OvmfPkg/MptScsiDxe: Report one Target and one LUN").

Because, even while we only support Target=0, the EFI_NOT_FOUND and
EFI_INVALID_PARAMETER return values of GetNextTarget() and
GetNextTargetLun(), could be distinguished.

Sorry for missing this under patch#6.


> @@ -595,6 +613,7 @@ MptScsiBuildDevicePath (
>    IN OUT EFI_DEVICE_PATH_PROTOCOL                  **DevicePath
>    )
>  {
> +  MPT_SCSI_DEV     *Dev;
>    SCSI_DEVICE_PATH *ScsiDevicePath;
>  
>    if (DevicePath == NULL) {
> @@ -605,7 +624,8 @@ MptScsiBuildDevicePath (
>    // This device support 256 targets only, so it's enough to dereference
>    // the LSB of Target.
>    //
> -  if (*Target > 0 || Lun > 0) {
> +  Dev = MPT_SCSI_FROM_PASS_THRU (This);
> +  if (*Target > Dev->MaxTarget || Lun > 0) {
>      return EFI_NOT_FOUND;
>    }
>  
> @@ -635,6 +655,7 @@ MptScsiGetTargetLun (
>    OUT UINT64                                       *Lun
>    )
>  {
> +  MPT_SCSI_DEV     *Dev;
>    SCSI_DEVICE_PATH *ScsiDevicePath;
>  
>    if (DevicePath == NULL ||
> @@ -647,8 +668,9 @@ MptScsiGetTargetLun (
>      return EFI_UNSUPPORTED;
>    }
>  
> +  Dev = MPT_SCSI_FROM_PASS_THRU (This);
>    ScsiDevicePath = (SCSI_DEVICE_PATH *)DevicePath;
> -  if (ScsiDevicePath->Pun > 0 ||
> +  if (ScsiDevicePath->Pun > Dev->MaxTarget ||
>        ScsiDevicePath->Lun > 0) {
>      return EFI_NOT_FOUND;
>    }
> diff --git a/OvmfPkg/MptScsiDxe/MptScsiDxe.inf b/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
> index ef1f6a5ebb3a..26aca7f95315 100644
> --- a/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
> +++ b/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
> @@ -37,3 +37,4 @@ [Protocols]
>  
>  [Pcd]
>    gUefiOvmfPkgTokenSpaceGuid.PcdMptScsiStallPerPollUsec ## CONSUMES
> +  gUefiOvmfPkgTokenSpaceGuid.PcdMptScsiMaxTargetLimit ## CONSUMES

(4) Please keep the PCD list alphabetically sorted, and also keep the
"## ... " comments lined up.

> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index 7fa1581f2101..7b56998abc9b 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -273,6 +273,10 @@ [PcdsFixedAtBuild]
>    ## Microseconds to stall between polling for MptScsi request result
>    gUefiOvmfPkgTokenSpaceGuid.PcdMptScsiStallPerPollUsec|5|UINT32|0x39
>  
> +  ## Set the *inclusive* number of targets that MptScsi exposes for scan
> +  #  by ScsiBusDxe.
> +  gUefiOvmfPkgTokenSpaceGuid.PcdMptScsiMaxTargetLimit|7|UINT8|0x40
> +

(5) Please keep this near the PcdPvScsi* group of PCDs.

>  [PcdsDynamic, PcdsDynamicEx]
>    gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
>    gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
> 

Thanks
Laszlo


  reply	other threads:[~2020-04-20 18:32 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-14 17:38 [PATCH v4 00/13] OvmfPkg: Support booting from Fusion-MPT SCSI controllers Nikita Leshenko
2020-04-14 17:38 ` [PATCH v4 01/13] OvmfPkg/MptScsiDxe: Create empty driver Nikita Leshenko
2020-04-15  6:31   ` [edk2-devel] " Laszlo Ersek
2020-04-14 17:38 ` [PATCH v4 02/13] OvmfPkg/MptScsiDxe: Install DriverBinding Protocol Nikita Leshenko
2020-04-14 17:38 ` [PATCH v4 03/13] OvmfPkg/MptScsiDxe: Report name of driver Nikita Leshenko
2020-04-14 17:38 ` [PATCH v4 04/13] OvmfPkg/MptScsiDxe: Probe PCI devices and look for MptScsi Nikita Leshenko
2020-04-14 17:38 ` [PATCH v4 05/13] OvmfPkg/MptScsiDxe: Install stubbed EXT_SCSI_PASS_THRU Nikita Leshenko
2020-04-15  6:54   ` [edk2-devel] " Laszlo Ersek
2020-04-14 17:38 ` [PATCH v4 06/13] OvmfPkg/MptScsiDxe: Report one Target and one LUN Nikita Leshenko
2020-04-14 17:38 ` [PATCH v4 07/13] OvmfPkg/MptScsiDxe: Build and decode DevicePath Nikita Leshenko
2020-04-15 12:03   ` [edk2-devel] " Laszlo Ersek
2020-04-14 17:38 ` [PATCH v4 08/13] OvmfPkg/MptScsiDxe: Open PciIo protocol for later use Nikita Leshenko
2020-04-16  8:05   ` [edk2-devel] " Laszlo Ersek
2020-04-14 17:38 ` [PATCH v4 09/13] OvmfPkg/MptScsiDxe: Set and restore PCI attributes Nikita Leshenko
2020-04-16  8:11   ` [edk2-devel] " Laszlo Ersek
2020-04-14 17:38 ` [PATCH v4 10/13] OvmfPkg/MptScsiDxe: Initialize hardware Nikita Leshenko
2020-04-16  9:53   ` [edk2-devel] " Laszlo Ersek
2020-04-16 16:00     ` Nikita Leshenko
2020-04-20 11:58       ` Laszlo Ersek
2020-04-20 14:10   ` Laszlo Ersek
2020-04-14 17:38 ` [PATCH v4 11/13] OvmfPkg/MptScsiDxe: Implement the PassThru method Nikita Leshenko
2020-04-20 17:30   ` [edk2-devel] " Laszlo Ersek
2020-04-24 17:03     ` Nikita Leshenko
2020-04-14 17:38 ` [PATCH v4 12/13] OvmfPkg/MptScsiDxe: Report multiple targets Nikita Leshenko
2020-04-20 18:31   ` Laszlo Ersek [this message]
2020-04-14 17:38 ` [PATCH v4 13/13] OvmfPkg/MptScsiDxe: Reset device on ExitBootServices() Nikita Leshenko
2020-04-20 19:02   ` [edk2-devel] " Laszlo Ersek

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-list 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=aa46e55b-496a-282f-4454-954b2db7935d@redhat.com \
    --to=devel@edk2.groups.io \
    /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