From: "Liran Alon" <liran.alon@oracle.com>
To: Laszlo Ersek <lersek@redhat.com>, devel@edk2.groups.io
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: Wed, 25 Mar 2020 03:11:33 +0200 [thread overview]
Message-ID: <eb3af241-71a6-aac6-ede1-022a6e74bf6a@oracle.com> (raw)
In-Reply-To: <c76ad219-8fa3-b746-ed1a-6147bc95fdee@redhat.com>
On 24/03/2020 18:00, Laszlo Ersek wrote:
> On 03/16/20 16:01, Liran Alon wrote:
>> +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)?
Nothing.
Besides the fact that all commands passed to this function are indeed
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).
Thanks for that. I think too it would be an overkill with little value.
> But, for this function, it really is unclear.
Will it be sufficient for you if I just replace the prototype with
something like the following?
/**
Send PVSCSI command to device
**/
STATIC
EFI_STATUS
PvScsiWriteCmdDesc (
IN CONST PVSCSI_DEV *Dev,
IN UINT32 Cmd,
IN VOID *Desc,
IN UINTN LengthInWords // Note: Word is UINT32
)
>> +
>> + 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 actually haven't noticed EfiPciIoWidthFifoUint32 until you mentioned it.
As it seems there isn't even a single line of code in EDK2 that use it. :)
In fact, the only code that use one of the EfiPciIoWidthFifo* is
MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c.
> (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.)
Why is this an issue?
It's easy to document with one-line comment at end of Desc parameter
deceleration that it must be aligned.
It's also not difficult to modify callers as only a single caller
actually pass a descriptor (The caller PvScsiInitRings()).
To avoid further style comments, what is the coding convention in EDK2
to align the "PVSCSI_CMD_DESC_SETUP_RINGS Cmd;" var properly?
In addition, I assume I don't need to add any validation of alignment to
PvScsiWriteCmdDesc().
-Liran
next prev parent reply other threads:[~2020-03-25 1:11 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 ` [edk2-devel] " Laszlo Ersek
2020-03-25 1:11 ` Liran Alon [this message]
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=eb3af241-71a6-aac6-ede1-022a6e74bf6a@oracle.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