From: "Laszlo Ersek" <lersek@redhat.com>
To: Liran Alon <liran.alon@oracle.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: [PATCH v2 13/17] OvmfPkg/PvScsiDxe: Setup requests and completions rings
Date: Thu, 26 Mar 2020 21:51:22 +0100 [thread overview]
Message-ID: <0739202a-9b8a-759d-5809-2f2df69e9352@redhat.com> (raw)
In-Reply-To: <20200325161005.16743-14-liran.alon@oracle.com>
On 03/25/20 17:10, Liran Alon wrote:
> These rings are shared memory buffers between host and device in which
> a cyclic buffer is managed to send request descriptors from host to
> device and receive completion descriptors from device to host.
>
> Note that because device may be constrained by IOMMU or guest may be run
> under AMD SEV, we make sure to map these rings to device by using
> PciIo->Map().
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567
> Signed-off-by: Liran Alon <liran.alon@oracle.com>
> ---
> OvmfPkg/PvScsiDxe/PvScsi.c | 269 +++++++++++++++++++++++++++++++++++++
> OvmfPkg/PvScsiDxe/PvScsi.h | 17 +++
> 2 files changed, 286 insertions(+)
>
> diff --git a/OvmfPkg/PvScsiDxe/PvScsi.c b/OvmfPkg/PvScsiDxe/PvScsi.c
> index 831a78cc18c7..59863f83c60c 100644
> --- a/OvmfPkg/PvScsiDxe/PvScsi.c
> +++ b/OvmfPkg/PvScsiDxe/PvScsi.c
> @@ -16,6 +16,7 @@
> #include <Library/UefiBootServicesTableLib.h>
> #include <Library/UefiLib.h>
> #include <Protocol/PciIo.h>
> +#include <Protocol/PciRootBridgeIo.h>
> #include <Uefi/UefiSpec.h>
>
> #include "PvScsi.h"
> @@ -413,6 +414,264 @@ PvScsiRestorePciAttributes (
> );
> }
>
> +STATIC
> +EFI_STATUS
> +PvScsiAllocatePages (
> + IN PVSCSI_DEV *Dev,
> + IN UINTN Pages,
> + IN OUT VOID **HostAddress
> + )
> +{
> + return Dev->PciIo->AllocateBuffer (
> + Dev->PciIo,
> + AllocateAnyPages,
> + EfiBootServicesData,
> + Pages,
> + HostAddress,
> + EFI_PCI_ATTRIBUTE_MEMORY_CACHED
> + );
> +}
> +
> +STATIC
> +VOID
> +PvScsiFreePages (
> + IN PVSCSI_DEV *Dev,
> + IN UINTN Pages,
> + IN VOID *HostAddress
> + )
> +{
> + Dev->PciIo->FreeBuffer (
> + Dev->PciIo,
> + Pages,
> + HostAddress
> + );
> +}
> +
> +STATIC
> +EFI_STATUS
> +PvScsiMapBuffer (
> + IN PVSCSI_DEV *Dev,
> + IN EFI_PCI_IO_PROTOCOL_OPERATION PciIoOperation,
> + IN VOID *HostAddress,
> + IN UINTN NumberOfBytes,
> + OUT PVSCSI_DMA_DESC *DmaDesc
> + )
> +{
> + EFI_STATUS Status;
> + UINTN BytesMapped;
> +
> + BytesMapped = NumberOfBytes;
> + Status = Dev->PciIo->Map (
> + Dev->PciIo,
> + PciIoOperation,
> + HostAddress,
> + &BytesMapped,
> + &DmaDesc->DeviceAddress,
> + &DmaDesc->Mapping
> + );
> + if (EFI_ERROR (Status)) {
> + return Status;
> + }
> +
> + if (BytesMapped != NumberOfBytes) {
> + Status = EFI_OUT_OF_RESOURCES;
> + goto Unmap;
> + }
> +
> + return EFI_SUCCESS;
> +
> +Unmap:
> + Dev->PciIo->Unmap (Dev->PciIo, DmaDesc->Mapping);
> +
> + return Status;
> +}
> +
> +STATIC
> +VOID
> +PvScsiUnmapBuffer (
> + IN PVSCSI_DEV *Dev,
> + IN OUT PVSCSI_DMA_DESC *DmaDesc)
> +{
> + Dev->PciIo->Unmap (Dev->PciIo, DmaDesc->Mapping);
> +}
> +
> +STATIC
> +EFI_STATUS
> +PvScsiAllocateSharedPages (
> + IN PVSCSI_DEV *Dev,
> + IN UINTN Pages,
> + IN EFI_PCI_IO_PROTOCOL_OPERATION PciIoOperation,
> + OUT VOID **HostAddress,
> + OUT PVSCSI_DMA_DESC *DmaDesc
> + )
> +{
> + EFI_STATUS Status;
> +
> + Status = PvScsiAllocatePages (Dev, Pages, HostAddress);
> + if (EFI_ERROR (Status)) {
> + return Status;
> + }
> +
> + Status = PvScsiMapBuffer (
> + Dev,
> + PciIoOperation,
> + *HostAddress,
> + EFI_PAGES_TO_SIZE (Pages),
> + DmaDesc
> + );
> + if (EFI_ERROR (Status)) {
> + goto FreePages;
> + }
> +
> + return EFI_SUCCESS;
> +
> +FreePages:
> + PvScsiFreePages (Dev, Pages, *HostAddress);
> +
> + return Status;
> +}
> +
> +STATIC
> +VOID
> +PvScsiFreeSharedPages (
> + IN PVSCSI_DEV *Dev,
> + IN UINTN Pages,
> + IN OUT VOID *HostAddress,
> + IN OUT PVSCSI_DMA_DESC *DmaDesc
> + )
> +{
> + PvScsiUnmapBuffer (Dev, DmaDesc);
> + PvScsiFreePages (Dev, Pages, HostAddress);
> +}
(1) From all of the above functions, please keep only two:
PvScsiAllocateSharedPages() and PvScsiFreeSharedPages(). The rest of the
helper functions should be flattened into them.
This is not a "frivolous" request -- it will make more sense once you
read my next request.
(2) Please eliminate the "PciIoOperation" parameter from the
PvScsiAllocateSharedPages() prototype, and open-code
"EfiPciIoOperationBusMasterCommonBuffer" in its place, in the
(flattened) implementation of the function.
Rationale: the buffer should be allocated separately with the
PciIo->AllocateBuffer() API *if and only if* a common buffer operation
is being set up. In other cases (one-shot bus master read, one-shot bus
master write), *only* the Map() operation should be used, and then Map()
and Unmap() will handle the bounce-buffering internally.
The functions above are misleading because they suggest they handle all
three bus master operations -- but for the one-shot BM read and write
operations, the PvScsiAllocateSharedPages() / PvScsiFreeSharedPages()
implementations are not correct.
Now, given that the call sites only set up common buffer operations, the
ultimately exercised logic is OK. And therefore the solution is not to
generalize the implementation uselessly (to BM read and BM write
operations too), but to tighten the interfaces such that they precisely
reflect the actual intended use case.
Hence, please open-code the common buffer operation internally to
PvScsiAllocateSharedPages(), and also stop exposing the separate
allocation / freeing / mapping / unmapping interfaces. The call sites
need nothing else than (a) "give me a completely mapped range for common
buffer operation" and (b) "release that".
Here's the (untested, not even compiled) implementation I propose:
> STATIC
> EFI_STATUS
> PvScsiAllocateSharedPages (
> IN PVSCSI_DEV *Dev,
> IN UINTN Pages,
> OUT VOID **HostAddress,
> OUT PVSCSI_DMA_DESC *DmaDesc
> )
> {
> EFI_STATUS Status;
> UINTN NumberOfBytes;
>
> Status = Dev->PciIo->AllocateBuffer (
> Dev->PciIo,
> AllocateAnyPages,
> EfiBootServicesData,
> Pages,
> HostAddress,
> EFI_PCI_ATTRIBUTE_MEMORY_CACHED
> );
> if (EFI_ERROR (Status)) {
> return Status;
> }
>
> NumberOfBytes = EFI_PAGES_TO_SIZE (Pages);
> Status = Dev->PciIo->Map (
> Dev->PciIo,
> EfiPciIoOperationBusMasterCommonBuffer,
> *HostAddress,
> &NumberOfBytes,
> &DmaDesc->DeviceAddress,
> &DmaDesc->Mapping
> );
> if (EFI_ERROR (Status)) {
> goto FreeBuffer;
> }
>
> if (NumberOfBytes != EFI_PAGES_TO_SIZE (Pages)) {
> Status = EFI_OUT_OF_RESOURCES;
> goto Unmap;
> }
>
> return EFI_SUCCESS;
>
> Unmap:
> Dev->PciIo->Unmap (Dev->PciIo, DmaDesc->Mapping);
>
> FreeBuffer:
> Dev->PciIo->FreeBuffer (Dev->PciIo, Pages, *HostAddress);
>
> return Status;
> }
>
> STATIC
> VOID
> PvScsiFreeSharedPages (
> IN PVSCSI_DEV *Dev,
> IN UINTN Pages,
> IN VOID *HostAddress,
> IN PVSCSI_DMA_DESC *DmaDesc
> )
> {
> Dev->PciIo->Unmap (Dev->PciIo, DmaDesc->Mapping);
> Dev->PciIo->FreeBuffer (Dev->PciIo, Pages, HostAddress);
> }
Back to your patch:
On 03/25/20 17:10, Liran Alon wrote:
> +
> +STATIC
> +EFI_STATUS
> +PvScsiInitRings (
> + IN OUT PVSCSI_DEV *Dev
> + )
> +{
> + EFI_STATUS Status;
> + PVSCSI_CMD_DESC_SETUP_RINGS Cmd;
> +
> + Status = PvScsiAllocateSharedPages (
> + Dev,
> + 1,
> + EfiPciIoOperationBusMasterCommonBuffer,
> + (VOID **)&Dev->RingDesc.RingState,
> + &Dev->RingDesc.RingStateDmaDesc
> + );
> + if (EFI_ERROR (Status)) {
> + return Status;
> + }
> + ZeroMem (Dev->RingDesc.RingState, EFI_PAGE_SIZE);
> +
> + Status = PvScsiAllocateSharedPages (
> + Dev,
> + 1,
> + EfiPciIoOperationBusMasterCommonBuffer,
> + (VOID **)&Dev->RingDesc.RingReqs,
> + &Dev->RingDesc.RingReqsDmaDesc
> + );
> + if (EFI_ERROR (Status)) {
> + goto FreeRingState;
> + }
> + ZeroMem (Dev->RingDesc.RingReqs, EFI_PAGE_SIZE);
> +
> + Status = PvScsiAllocateSharedPages (
> + Dev,
> + 1,
> + EfiPciIoOperationBusMasterCommonBuffer,
> + (VOID **)&Dev->RingDesc.RingCmps,
> + &Dev->RingDesc.RingCmpsDmaDesc
> + );
> + if (EFI_ERROR (Status)) {
> + goto FreeRingReqs;
> + }
> + ZeroMem (Dev->RingDesc.RingCmps, EFI_PAGE_SIZE);
> +
> + ZeroMem (&Cmd, sizeof (Cmd));
> + Cmd.ReqRingNumPages = 1;
> + Cmd.CmpRingNumPages = 1;
> + Cmd.RingsStatePPN = RShiftU64 (
> + (UINT64)Dev->RingDesc.RingStateDmaDesc.DeviceAddress,
> + EFI_PAGE_SHIFT
> + );
> + Cmd.ReqRingPPNs[0] = RShiftU64 (
> + (UINT64)Dev->RingDesc.RingReqsDmaDesc.DeviceAddress,
> + EFI_PAGE_SHIFT
> + );
> + Cmd.CmpRingPPNs[0] = RShiftU64 (
> + (UINT64)Dev->RingDesc.RingCmpsDmaDesc.DeviceAddress,
> + EFI_PAGE_SHIFT
> + );
(3) Please drop the explicit UINT64 casts -- for brevity --,
EFI_PHYSICAL_ADDRESS is just a different name (a typedef) for UINT64, by
spec. (See in the EFI_BOOT_SERVICES.AllocatePages() chapter in the UEFI
spec.)
(4) Please #include <Library/BaseLib.h> in the C file, and also list
BaseLib under [LibraryClasses] in the INF file. RShiftU64() comes from
there.
> +
> + Status = PvScsiWriteCmdDesc (
> + Dev,
> + PvScsiCmdSetupRings,
> + (UINT32 *)&Cmd,
(5) So I guess this is where the "union trick" will come, in v3.
> + sizeof (Cmd) / sizeof (UINT32)
(6) Can you please try inserting, before the PvScsiWriteCmdDesc() call:
STATIC_ASSERT (sizeof Cmd % sizeof (UINT32) == 0, "invalid Cmd size");
> + );
> + if (EFI_ERROR (Status)) {
> + goto FreeRingCmps;
> + }
> +
> + return EFI_SUCCESS;
> +
> +FreeRingCmps:
> + PvScsiFreeSharedPages (
> + Dev,
> + 1,
> + Dev->RingDesc.RingCmps,
> + &Dev->RingDesc.RingCmpsDmaDesc
> + );
> +
> +FreeRingReqs:
> + PvScsiFreeSharedPages (
> + Dev,
> + 1,
> + Dev->RingDesc.RingReqs,
> + &Dev->RingDesc.RingReqsDmaDesc
> + );
> +
> +FreeRingState:
> + PvScsiFreeSharedPages (
> + Dev,
> + 1,
> + Dev->RingDesc.RingState,
> + &Dev->RingDesc.RingStateDmaDesc
> + );
> +
> + return Status;
> +}
> +
> +STATIC
> +VOID
> +PvScsiFreeRings (
> + IN OUT PVSCSI_DEV *Dev
> + )
> +{
> + PvScsiFreeSharedPages (
> + Dev,
> + 1,
> + Dev->RingDesc.RingCmps,
> + &Dev->RingDesc.RingCmpsDmaDesc
> + );
> +
> + PvScsiFreeSharedPages (
> + Dev,
> + 1,
> + Dev->RingDesc.RingReqs,
> + &Dev->RingDesc.RingReqsDmaDesc
> + );
> +
> + PvScsiFreeSharedPages (
> + Dev,
> + 1,
> + Dev->RingDesc.RingState,
> + &Dev->RingDesc.RingStateDmaDesc
> + );
> +}
> +
(7) This function is almost correct.
Note that your last *such* action in PvScsiInitRings() that impacts any
resource life cycle is the *exposure* of the rings to the device model
(the hypervisor).
Therefore, after PvScsiInitRings() succeeds, then on any subsequently
occurring error path, you first need to make the device model forget
about the rings, before you release the rings. A hypervisor-side
reference to guest memory is just another resource you "allocate", so
you need to drop it too, in reverse order of construction.
In brief, please add the following to the top of the PvScsiFreeRings()
function:
PvScsiWriteCmdDesc (Dev, PvScsiCmdAdapterReset, NULL, 0);
(Consider, for example, what would happen *otherwise*, if the DmaBuf
allocation failed -- in the next patch -- in the PvScsiInit() function.
There, you jump to "FreeRings" correctly, and release the rings with
PvScsiFreeRings() -- but the hypervisor still remembers them!)
> STATIC
> EFI_STATUS
> PvScsiInit (
> @@ -443,6 +702,14 @@ PvScsiInit (
> goto RestorePciAttributes;
> }
>
> + //
> + // Init PVSCSI rings
> + //
> + Status = PvScsiInitRings (Dev);
> + if (EFI_ERROR (Status)) {
> + goto RestorePciAttributes;
> + }
> +
> //
> // Populate the exported interface's attributes
> //
> @@ -486,6 +753,8 @@ PvScsiUninit (
> IN OUT PVSCSI_DEV *Dev
> )
> {
> + PvScsiFreeRings (Dev);
> +
> PvScsiRestorePciAttributes (Dev);
> }
>
> diff --git a/OvmfPkg/PvScsiDxe/PvScsi.h b/OvmfPkg/PvScsiDxe/PvScsi.h
> index 5f611dbbc98c..6d23b6e1eccf 100644
> --- a/OvmfPkg/PvScsiDxe/PvScsi.h
> +++ b/OvmfPkg/PvScsiDxe/PvScsi.h
> @@ -15,12 +15,29 @@
> #include <Library/DebugLib.h>
> #include <Protocol/ScsiPassThruExt.h>
>
> +typedef struct {
> + EFI_PHYSICAL_ADDRESS DeviceAddress;
> + VOID *Mapping;
> +} PVSCSI_DMA_DESC;
> +
> +typedef struct {
> + PVSCSI_RINGS_STATE *RingState;
> + PVSCSI_DMA_DESC RingStateDmaDesc;
> +
> + PVSCSI_RING_REQ_DESC *RingReqs;
> + PVSCSI_DMA_DESC RingReqsDmaDesc;
> +
> + PVSCSI_RING_CMP_DESC *RingCmps;
> + PVSCSI_DMA_DESC RingCmpsDmaDesc;
> +} PVSCSI_RING_DESC;
> +
> #define PVSCSI_SIG SIGNATURE_32 ('P', 'S', 'C', 'S')
>
> typedef struct {
> UINT32 Signature;
> EFI_PCI_IO_PROTOCOL *PciIo;
> UINT64 OriginalPciAttributes;
> + PVSCSI_RING_DESC RingDesc;
> UINT8 MaxTarget;
> UINT8 MaxLun;
> EFI_EXT_SCSI_PASS_THRU_PROTOCOL PassThru;
>
These look fine.
(8) A general request regarding your git setup: please run the
"BaseTools/Scripts/SetupGit.py" script in your edk2 clone.
The reason I'm asking for that right now is that the script will point
the "diff.orderFile" setting to "BaseTools/Conf/diff.order". And that
will make git-format-patch, on your end, place the header file changes
ahead of the C file changes, in the generated emails.
It helps reviewers greatly if they can first see the declarative changes
(such as new types, new structure members, and so on), before they face
the code using the new constructs.
The script in question configures a bunch of other cool stuff too that
boosts reviewer productivity.
Thanks,
Laszlo
next prev parent reply other threads:[~2020-03-26 20:51 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-25 16:09 [PATCH v2 00/17] OvmfPkg: Support booting from VMware PVSCSI controller Liran Alon
2020-03-25 16:09 ` [PATCH v2 01/17] OvmfPkg/PvScsiDxe: Create empty driver Liran Alon
2020-03-26 14:44 ` [edk2-devel] " Laszlo Ersek
2020-03-25 16:09 ` [PATCH v2 02/17] OvmfPkg/PvScsiDxe: Install DriverBinding protocol Liran Alon
2020-03-25 16:09 ` [PATCH v2 03/17] OvmfPkg/PvScsiDxe: Report name of driver Liran Alon
2020-03-25 16:09 ` [PATCH v2 04/17] OvmfPkg/PvScsiDxe: Probe PCI devices and look for PvScsi Liran Alon
2020-03-25 16:09 ` [PATCH v2 05/17] OvmfPkg/PvScsiDxe: Install stubbed EXT_SCSI_PASS_THRU Liran Alon
2020-03-25 16:09 ` [PATCH v2 06/17] OvmfPkg/PvScsiDxe: Report the number of targets and LUNs Liran Alon
2020-03-25 16:09 ` [PATCH v2 07/17] OvmfPkg/PvScsiDxe: Translate Target & LUN to/from DevicePath Liran Alon
2020-03-25 16:09 ` [PATCH v2 08/17] OvmfPkg/PvScsiDxe: Open PciIo protocol for later use Liran Alon
2020-03-25 16:09 ` [PATCH v2 09/17] OvmfPkg/PvScsiDxe: Backup/Restore PCI attributes on Init/UnInit Liran Alon
2020-03-26 17:04 ` [edk2-devel] " Laszlo Ersek
2020-03-25 16:09 ` [PATCH v2 10/17] OvmfPkg/PvScsiDxe: Enable MMIO-Space & Bus-Mastering in PCI attributes Liran Alon
2020-03-26 17:12 ` Laszlo Ersek
2020-03-25 16:09 ` [PATCH v2 11/17] OvmfPkg/PvScsiDxe: Define device interface structures and constants Liran Alon
2020-03-26 17:19 ` [edk2-devel] " Laszlo Ersek
2020-03-25 16:10 ` [PATCH v2 12/17] OvmfPkg/PvScsiDxe: Reset adapter on init Liran Alon
2020-03-26 18:25 ` [edk2-devel] " Laszlo Ersek
2020-03-25 16:10 ` [PATCH v2 13/17] OvmfPkg/PvScsiDxe: Setup requests and completions rings Liran Alon
2020-03-26 20:51 ` Laszlo Ersek [this message]
2020-03-25 16:10 ` [PATCH v2 14/17] OvmfPkg/PvScsiDxe: Introduce DMA communication buffer Liran Alon
2020-03-26 22:17 ` Laszlo Ersek
2020-03-27 0:05 ` Liran Alon
2020-03-27 13:35 ` Laszlo Ersek
2020-03-27 21:31 ` Liran Alon
2020-03-30 11:29 ` Laszlo Ersek
2020-03-25 16:10 ` [PATCH v2 15/17] OvmfPkg/PvScsiDxe: Support sending SCSI request and receive response Liran Alon
2020-03-27 11:26 ` [edk2-devel] " Laszlo Ersek
2020-03-27 13:04 ` Liran Alon
2020-03-27 13:20 ` Liran Alon
2020-03-27 21:05 ` Laszlo Ersek
2020-03-27 21:05 ` Laszlo Ersek
2020-03-27 22:04 ` Liran Alon
2020-03-27 22:17 ` Liran Alon
2020-03-28 19:18 ` Liran Alon
2020-03-30 11:23 ` Laszlo Ersek
2020-03-30 11:12 ` Laszlo Ersek
2020-03-30 10:30 ` Laszlo Ersek
2020-03-25 16:10 ` [PATCH v2 16/17] OvmfPkg/PvScsiDxe: Reset device on ExitBootServices() Liran Alon
2020-03-25 16:10 ` [PATCH v2 17/17] OvmfPkg/PvScsiDxe: Enable device 64-bit DMA addresses Liran Alon
2020-03-26 22:29 ` [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=0739202a-9b8a-759d-5809-2f2df69e9352@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