public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: devel@edk2.groups.io, liran.alon@oracle.com
Cc: nikita.leshchenko@oracle.com, aaron.young@oracle.com,
	jordan.l.justen@intel.com, ard.biesheuvel@linaro.org
Subject: Re: [edk2-devel] [PATCH 12/17] OvmfPkg/PvScsiDxe: Reset adapter on init
Date: Tue, 24 Mar 2020 17:00:10 +0100	[thread overview]
Message-ID: <c76ad219-8fa3-b746-ed1a-6147bc95fdee@redhat.com> (raw)
In-Reply-To: <20200316150113.104630-13-liran.alon@oracle.com>

a bit more superficial comments, for now:

On 03/16/20 16:01, Liran Alon wrote:
> The following commits will complete the implementation of
> device initialization.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567
> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
> Signed-off-by: Liran Alon <liran.alon@oracle.com>
> ---
>  OvmfPkg/PvScsiDxe/PvScsi.c | 77 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 77 insertions(+)
>
> diff --git a/OvmfPkg/PvScsiDxe/PvScsi.c b/OvmfPkg/PvScsiDxe/PvScsi.c
> index ff6b50b7020f..fb2407d2adb2 100644
> --- a/OvmfPkg/PvScsiDxe/PvScsi.c
> +++ b/OvmfPkg/PvScsiDxe/PvScsi.c
> @@ -29,6 +29,76 @@
>  // Ext SCSI Pass Thru utilities
>  //
>
> +
> +//
> +// Writes a 32-bit value into BAR0 using MMIO
> +//

(1) Please use the /** **/ comment style for top-level function comment
blocks.

> +STATIC
> +EFI_STATUS
> +PvScsiMmioWrite32 (
> +  IN CONST PVSCSI_DEV   *Dev,
> +  IN UINT64             Offset,
> +  IN UINT32             Value
> +  )
> +{
> +  return Dev->PciIo->Mem.Write(
> +                           Dev->PciIo,
> +                           EfiPciIoWidthUint32,
> +                           0,   // BarIndex

(2) Style improvement: please use the PCI_BAR_IDX0 macro.

> +                           Offset,
> +                           1,   // Count
> +                           &Value
> +                           );
> +}
> +
> +//
> +// Send PVSCSI command to device
> +//

(3) Same as (1).

> +STATIC
> +EFI_STATUS
> +PvScsiWriteCmdDesc (
> +  IN CONST PVSCSI_DEV   *Dev,
> +  IN UINT32             Cmd,
> +  IN VOID               *Desc,
> +  IN UINTN              Length
> +  )
> +{
> +  EFI_STATUS Status;
> +  UINTN      LengthInWords;
> +  UINT8      *WordPtr;
> +  UINT8      *DescEndPtr;
> +  UINT32     Word;
> +
> +  LengthInWords = Length / sizeof (UINT32);

(4) What guarantees that "Length" is a whole multiple of sizeof
(UINT32)?

In this review I have not insisted on including full-blown interface
contracts in the top-level function comment blocks (with @param[in] and
@retval etc). But, for this function, it really is unclear.

> +
> +  if (LengthInWords > PVSCSI_MAX_CMD_DATA_WORDS) {
> +    return EFI_INVALID_PARAMETER;
> +  }
> +
> +  Status = PvScsiMmioWrite32 (Dev, PVSCSI_REG_OFFSET_COMMAND, Cmd);
> +  if (EFI_ERROR (Status)) {
> +    return Status;
> +  }
> +
> +  WordPtr = Desc;
> +  DescEndPtr = WordPtr + Length;
> +
> +  while (WordPtr != DescEndPtr) {
> +    //
> +    // CopyMem() is used to avoid strict-aliasing issues
> +    //

(5) In edk2, we -- completely intentionally -- disable the enforcement
of the effective type rules / strict aliasing rules. See
"-fno-strict-aliasing" in "BaseTools/Conf/tools_def.template".

> +    CopyMem (&Word, WordPtr, sizeof (UINT32));
> +
> +    Status = PvScsiMmioWrite32 (Dev, PVSCSI_REG_OFFSET_COMMAND_DATA, Word);
> +    if (EFI_ERROR (Status)) {
> +      return Status;
> +    }
> +
> +    WordPtr += sizeof (UINT32);
> +  }
> +
> +  return EFI_SUCCESS;
> +}

(6) I think the open-coded loop is suboptimal -- the PciIo protocol
seems to offer EfiPciIoWidthFifoUint32 for exactly this purpose (=
advance in the memory buffer, while accessing the same offset in the
BAR).

Have you perhaps tried that?

(I can imagine that you ruled it out, due to "Desc" being unaligned. The
UEFI spec does say, "The caller is responsible for any alignment and I/O
width issues which the bus, device, platform, or type of I/O might
require.)

>  //
>  // Check if Target argument to EXT_SCSI_PASS_THRU.GetNextTarget() and
>  // EXT_SCSI_PASS_THRU.GetNextTargetLun() is initialized
> @@ -348,6 +418,13 @@ PvScsiInit (
>      return Status;
>    }
>
> +  //
> +  // Reset adapter
> +  //
> +  Status = PvScsiWriteCmdDesc (Dev, PVSCSI_CMD_ADAPTER_RESET, NULL, 0);
> +  if (EFI_ERROR (Status)) {
> +    return Status;
> +  }
>    //
>    // Populate the exported interface's attributes
>    //
>

OK, so this ties back to my comments on resource management, under
patch#9.

Let me quote the PvScsiInit() function in full, after the present patch
is applied:

> STATIC
> EFI_STATUS
> PvScsiInit (
>   IN OUT PVSCSI_DEV *Dev
>   )
> {
>   EFI_STATUS Status;
>
>   //
>   // Init configuration
>   //
>   Dev->MaxTarget = PcdGet8 (PcdPvScsiMaxTargetLimit);
>   Dev->MaxLun = PcdGet8 (PcdPvScsiMaxLunLimit);
>
>   //
>   // Set PCI Attributes
>   //
>   Status = PvScsiSetPCIAttributes (Dev);
>   if (EFI_ERROR (Status)) {
>     return Status;
>   }
>
>   //
>   // Reset adapter
>   //
>   Status = PvScsiWriteCmdDesc (Dev, PVSCSI_CMD_ADAPTER_RESET, NULL, 0);
>   if (EFI_ERROR (Status)) {
>     return Status;
>   }

(7) So this is precisely the spot where we have to jump to a new error
handling label -- called "RestorePciAttributes" --, to be introduced at
the end of the function. And we need to call
PvScsiRestorePciAttributes() there.

Otherwise, the original PCI attributes will never be restored.

Thanks!
Laszlo

On 03/16/20 16:01, Liran Alon wrote:
>   //
>   // Populate the exported interface's attributes
>   //
>   Dev->PassThru.Mode             = &Dev->PassThruMode;
>   Dev->PassThru.PassThru         = &PvScsiPassThru;
>   Dev->PassThru.GetNextTargetLun = &PvScsiGetNextTargetLun;
>   Dev->PassThru.BuildDevicePath  = &PvScsiBuildDevicePath;
>   Dev->PassThru.GetTargetLun     = &PvScsiGetTargetLun;
>   Dev->PassThru.ResetChannel     = &PvScsiResetChannel;
>   Dev->PassThru.ResetTargetLun   = &PvScsiResetTargetLun;
>   Dev->PassThru.GetNextTarget    = &PvScsiGetNextTarget;
>
>   //
>   // AdapterId is a target for which no handle will be created during bus scan.
>   // Prevent any conflict with real devices.
>   //
>   Dev->PassThruMode.AdapterId = MAX_UINT32;
>
>   //
>   // Set both physical and logical attributes for non-RAID SCSI channel
>   //
>   Dev->PassThruMode.Attributes = EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL |
>                                  EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL;
>
>   //
>   // No restriction on transfer buffer alignment
>   //
>   Dev->PassThruMode.IoAlign = 0;
>
>   return EFI_SUCCESS;
> }


  reply	other threads:[~2020-03-24 16:00 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-16 15:00 [PATCH 00/17]: OvmfPkg: Support booting from VMware PVSCSI controller liran.alon
2020-03-16 15:00 ` [PATCH 01/17] OvmfPkg/PvScsiDxe: Create empty driver Liran Alon
2020-03-24 11:15   ` [edk2-devel] " Laszlo Ersek
2020-03-16 15:00 ` [PATCH 02/17] OvmfPkg/PvScsiDxe: Install DriverBinding protocol Liran Alon
2020-03-24 11:23   ` [edk2-devel] " Laszlo Ersek
2020-03-16 15:00 ` [PATCH 03/17] OvmfPkg/PvScsiDxe: Report name of driver Liran Alon
2020-03-24 11:29   ` [edk2-devel] " Laszlo Ersek
2020-03-16 15:01 ` [PATCH 04/17] OvmfPkg/PvScsiDxe: Probe PCI devices and look for PvScsi Liran Alon
2020-03-24 11:41   ` [edk2-devel] " Laszlo Ersek
2020-03-16 15:01 ` [PATCH 05/17] OvmfPkg/PvScsiDxe: Install stubbed EXT_SCSI_PASS_THRU Liran Alon
2020-03-24 12:27   ` [edk2-devel] " Laszlo Ersek
2020-03-24 12:47     ` Laszlo Ersek
2020-03-16 15:01 ` [PATCH 06/17] OvmfPkg/PvScsiDxe: Report the number of targets and LUNs Liran Alon
2020-03-24 13:12   ` [edk2-devel] " Laszlo Ersek
2020-03-16 15:01 ` [PATCH 07/17] OvmfPkg/PvScsiDxe: Translate Target & LUN to/from DevicePath Liran Alon
2020-03-24 13:36   ` [edk2-devel] " Laszlo Ersek
2020-03-16 15:01 ` [PATCH 08/17] OvmfPkg/PvScsiDxe: Open PciIo protocol for later use Liran Alon
2020-03-24 13:47   ` [edk2-devel] " Laszlo Ersek
2020-03-16 15:01 ` [PATCH 09/17] OvmfPkg/PvScsiDxe: Backup/Restore PCI attributes on Init/UnInit Liran Alon
2020-03-24 15:14   ` [edk2-devel] " Laszlo Ersek
2020-03-24 15:35     ` Liran Alon
2020-03-25  1:48       ` Laszlo Ersek
2020-03-25 10:32         ` Liran Alon
2020-03-16 15:01 ` [PATCH 10/17] OvmfPkg/PvScsiDxe: Enable IOSpace & Bus-Mastering in PCI attributes Liran Alon
2020-03-24 15:22   ` [edk2-devel] " Laszlo Ersek
2020-03-16 15:01 ` [PATCH 11/17] OvmfPkg/PvScsiDxe: Define device interface structures and constants Liran Alon
2020-03-24 15:35   ` [edk2-devel] " Laszlo Ersek
2020-03-24 16:34     ` Laszlo Ersek
2020-03-16 15:01 ` [PATCH 12/17] OvmfPkg/PvScsiDxe: Reset adapter on init Liran Alon
2020-03-24 16:00   ` Laszlo Ersek [this message]
2020-03-25  1:11     ` [edk2-devel] " Liran Alon
2020-03-25 16:31       ` Laszlo Ersek
2020-03-25 16:40         ` Liran Alon
2020-03-25 17:13           ` Liran Alon
2020-03-27 12:55             ` Laszlo Ersek
2020-03-16 15:01 ` [PATCH 13/17] OvmfPkg/PvScsiDxe: Setup requests and completions rings Liran Alon
2020-03-24 16:11   ` [edk2-devel] " Laszlo Ersek
2020-03-16 15:01 ` [PATCH 14/17] OvmfPkg/PvScsiDxe: Introduce DMA communication buffer Liran Alon
2020-03-24 16:13   ` [edk2-devel] " Laszlo Ersek
2020-03-16 15:01 ` [PATCH 15/17] OvmfPkg/PvScsiDxe: Support sending SCSI request and receive response Liran Alon
2020-03-24 16:43   ` [edk2-devel] " Laszlo Ersek
2020-03-25  1:17     ` Liran Alon
2020-03-16 15:01 ` [PATCH 16/17] OvmfPkg/PvScsiDxe: Reset device on ExitBootServices() Liran Alon
2020-03-24 17:04   ` [edk2-devel] " Laszlo Ersek
2020-03-16 15:01 ` [PATCH 17/17] OvmfPkg/PvScsiDxe: Enable device 64-bit DMA addresses Liran Alon
2020-03-24 15:26   ` [edk2-devel] " Laszlo Ersek
2020-03-23 16:33 ` [edk2-devel] [PATCH 00/17]: OvmfPkg: Support booting from VMware PVSCSI controller 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=c76ad219-8fa3-b746-ed1a-6147bc95fdee@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