public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Brijesh Singh <brijesh.singh@amd.com>, edk2-devel@lists.01.org
Cc: Jordan Justen <jordan.l.justen@intel.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH v2 12/23] OvmfPkg/VirtioLib: add functions to map/unmap VRING
Date: Wed, 16 Aug 2017 22:56:38 +0200	[thread overview]
Message-ID: <72c6cdca-8364-bb2d-227d-30278d9d086a@redhat.com> (raw)
In-Reply-To: <1502710605-8058-13-git-send-email-brijesh.singh@amd.com>

On 08/14/17 13:36, Brijesh Singh wrote:
> Add functions to map and unmap the ring buffer with BusMasterCommonBuffer
> so that ring can be accessed by both guest and hypervisor.
> 
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
>  OvmfPkg/Include/Library/VirtioLib.h   | 25 +++++++++++
>  OvmfPkg/Library/VirtioLib/VirtioLib.c | 44 ++++++++++++++++++++
>  2 files changed, 69 insertions(+)

(1) The subject and the commit message both should say "a function"
(singular) now -- we've only kept VirtioRingMap().

Unmap shoud not be referenced in either the subject or the commit message.

> 
> diff --git a/OvmfPkg/Include/Library/VirtioLib.h b/OvmfPkg/Include/Library/VirtioLib.h
> index ca0b217a04eb..1efb02a68cf1 100644
> --- a/OvmfPkg/Include/Library/VirtioLib.h
> +++ b/OvmfPkg/Include/Library/VirtioLib.h
> @@ -62,6 +62,31 @@ VirtioRingInit (
>  
>  /**
>  
> +  Map the ring buffer so that it can be accessed equally by both guest
> +  and hypervisor.
> +
> +  @param[in]      VirtIo          The virtio device instance.
> +
> +  @param[in]      Ring            The virtio ring to map.
> +
> +  @param[out]     RingBaseShift   

The fact that you either forgot, or had difficulties with, the
explanation of the RingBaseShift output parameter, is not random. It has
a deeper cause.

The cause is that placing this patch at this exact position in the
series constitutes a layering violation.

In my previous review
<http://mid.mail-archive.com/01220a3b-565b-8a36-406d-cfcc63265fb7@redhat.com>,
point (10), I tried to clarify this ("*Then* please include the present
patch", emphasis added now), but I must have been unclear.

So, the idea is that
- the VirtioLib helper functions (code, comments, and commit messages)
are allowed to reference VIRTIO_DEVICE_PROTOCOL specifics,
- but references in the opposite direction should be avoided if possible.

You are introducing this patch at position 12 in the series, and in the
next patch, for the virtio protocol, you refer to VirtioRingMap() in the
commit message. This should not be done -- the opposite dependency
should be constructed.

(2) So please, move this patch two positions toward the tail of the series:

  OvmfPkg/VirtioLib: add functions to map/unmap VRING -----------+
  OvmfPkg/Virtio: take RingBaseShift in VirtioSetQueueAddress()  |
  OvmfPkg/Virtio10Dxe: add the RingBaseShift offset              |
  <HERE> <-------------------------------------------------------+
  OvmfPkg/VirtioLib: alloc vring buffer with AllocateSharedPages()

(3) Then you can document the RingBaseShift parameter simply like this,
in this patch:

  @param[out] RingBaseShift  A resulting translation offset, to be
                             passed to VirtIo->SetQueueAddress().


> +
> +  @param[out]     Mapping         A resulting token to pass to
> +                                  VirtIo->UnmapSharedBuffer().
> +
> +  @return         Status from VirtIo->MapSharedBuffer()

(4) This is an improvement on the previous version of the patch, but the
.c and .h files differ ("Status code" vs "Status").

So please sync the full comment blocks (after addressing (3) as well).

> +**/
> +EFI_STATUS
> +EFIAPI
> +VirtioRingMap (
> +  IN  VIRTIO_DEVICE_PROTOCOL *VirtIo,
> +  IN  VRING                  *Ring,
> +  OUT UINT64                 *RingBaseShift,
> +  OUT VOID                   **Mapping
> +  );
> +
> +/**
> +
>    Tear down the internal resources of a configured virtio ring.
>  
>    The caller is responsible to stop the host from using this ring before
> diff --git a/OvmfPkg/Library/VirtioLib/VirtioLib.c b/OvmfPkg/Library/VirtioLib/VirtioLib.c
> index 5b64d18a8d6f..7d07dcc09d3d 100644
> --- a/OvmfPkg/Library/VirtioLib/VirtioLib.c
> +++ b/OvmfPkg/Library/VirtioLib/VirtioLib.c
> @@ -498,3 +498,47 @@ Failed:
>    *Mapping = NULL;
>    return EFI_OUT_OF_RESOURCES;
>  }
> +
> +/**
> +
> +  Map the ring buffer so that it can be accessed equally by both guest
> +  and hypervisor.
> +
> +  @param[in]      VirtIo          The virtio device instance.
> +
> +  @param[in]      Ring            The virtio ring to map.
> +
> +  @param[out]     RingBaseShift   RingBaseShift
> +
> +  @param[out]     Mapping         A resulting token to pass to
> +                                  VirtIo->UnmapSharedBuffer().
> +
> +  @return         Status code from VirtIo->MapSharedBuffer()
> +**/
> +EFI_STATUS
> +EFIAPI
> +VirtioRingMap (
> +  IN  VIRTIO_DEVICE_PROTOCOL *VirtIo,
> +  IN  VRING                  *Ring,
> +  OUT UINT64                 *RingBaseShift,
> +  OUT VOID                   **Mapping
> +  )
> +{
> +  EFI_STATUS        Status;
> +  PHYSICAL_ADDRESS  DeviceAddress;

(5) Technically this is correct (both EFI_PHYSICAL_ADDRESS and
PHYSICAL_ADDRESS are typedefs for UINT64).

For consistency with the prototype of VirtioMapAllBytesInSharedBuffer(),
EFI_PHYSICAL_ADDRESS would be slightly better in my opinion.

> +
> +  Status = VirtioMapAllBytesInSharedBuffer (
> +             VirtIo,
> +             VirtioOperationBusMasterCommonBuffer,
> +             Ring->Base,
> +             EFI_PAGES_TO_SIZE (Ring->NumPages),
> +             &DeviceAddress,
> +             Mapping

This is fine -- we're passing "Mapping" directly to
VirtioMapAllBytesInSharedBuffer(), but we know that said function won't
modify Mapping if it fails.

(Just please address point (8) in my "PATCH v2 10/23" feedback -- i.e.,
VirtioMapAllBytesInSharedBuffer() should not null "Mapping" on error.)

> +             );
> +  if (EFI_ERROR (Status)) {
> +    return Status;
> +  }
> +
> +  *RingBaseShift = DeviceAddress - (UINT64)(UINTN)Ring->Base;
> +  return EFI_SUCCESS;
> +}
> 

Looks good!

Thank you!
Laszlo


  reply	other threads:[~2017-08-16 20:54 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-14 11:36 [PATCH v2 00/21] OvmfPkg/Virtio: introduce IOMMU-like member functions Brijesh Singh
2017-08-14 11:36 ` [PATCH v2 01/23] OvmfPkg/VirtioPciDeviceDxe: supply missing BUS_MASTER attribute Brijesh Singh
2017-08-16  0:34   ` Laszlo Ersek
2017-08-14 11:36 ` [PATCH v2 02/23] OvmfPkg/Virtio10Dxe: " Brijesh Singh
2017-08-16  0:36   ` Laszlo Ersek
2017-08-14 11:36 ` [PATCH v2 03/23] OvmfPkg/VirtioPciDeviceDxe: add missing IN and OUT decoration Brijesh Singh
2017-08-16  0:36   ` Laszlo Ersek
2017-08-14 11:36 ` [PATCH v2 04/23] OvmfPkg/VirtioMmioDeviceLib: " Brijesh Singh
2017-08-16  0:37   ` Laszlo Ersek
2017-08-14 11:36 ` [PATCH v2 05/23] OvmfPkg/Virtio: fix comment style Brijesh Singh
2017-08-16  0:41   ` Laszlo Ersek
2017-08-14 11:36 ` [PATCH v2 06/23] OvmfPkg/Virtio: introduce IOMMU-like member functions to VIRTIO_DEVICE_PROTOCOL Brijesh Singh
2017-08-16 14:37   ` Laszlo Ersek
2017-08-16 15:58     ` Brijesh Singh
2017-08-14 11:36 ` [PATCH v2 07/23] OvmfPkg/Virtio10Dxe: implement IOMMU-like member functions Brijesh Singh
2017-08-16 14:59   ` Laszlo Ersek
2017-08-14 11:36 ` [PATCH v2 08/23] OvmfPkg/VirtioPciDeviceDxe: " Brijesh Singh
2017-08-16 15:32   ` Laszlo Ersek
2017-08-16 15:53     ` Brijesh Singh
2017-08-14 11:36 ` [PATCH v2 09/23] OvmfPkg/VirtioMmioDeviceLib: " Brijesh Singh
2017-08-16 15:58   ` Laszlo Ersek
2017-08-14 11:36 ` [PATCH v2 10/23] OvmfPkg/VirtioLib: add VirtioMapAllBytesInSharedBuffer() helper function Brijesh Singh
2017-08-16 16:47   ` Laszlo Ersek
2017-08-14 11:36 ` [PATCH v2 11/23] OvmfPkg/VirtioLib: take VirtIo instance in VirtioRingInit/VirtioRingUninit Brijesh Singh
2017-08-16 16:53   ` Laszlo Ersek
2017-08-14 11:36 ` [PATCH v2 12/23] OvmfPkg/VirtioLib: add functions to map/unmap VRING Brijesh Singh
2017-08-16 20:56   ` Laszlo Ersek [this message]
2017-08-14 11:36 ` [PATCH v2 13/23] OvmfPkg/Virtio: take RingBaseShift in VirtioSetQueueAddress() Brijesh Singh
2017-08-16 21:43   ` Laszlo Ersek
2017-08-16 21:51     ` Laszlo Ersek
2017-08-14 11:36 ` [PATCH v2 14/23] OvmfPkg/Virtio10Dxe: add the RingBaseShift offset Brijesh Singh
2017-08-16 21:57   ` Laszlo Ersek
2017-08-14 11:36 ` [PATCH v2 15/23] OvmfPkg/VirtioLib: alloc vring buffer with AllocateSharedPages() Brijesh Singh
2017-08-16 22:18   ` Laszlo Ersek
2017-08-14 11:36 ` [PATCH v2 16/23] OvmfPkg/VirtioRngDxe: map host address to device address Brijesh Singh
2017-08-21 14:05   ` Laszlo Ersek
2017-08-22 15:44     ` Brijesh Singh
2017-08-22 16:28       ` Laszlo Ersek
2017-08-14 11:36 ` [PATCH v2 17/23] OvmfPkg/VirtioBlkDxe: " Brijesh Singh
2017-08-21 15:24   ` Laszlo Ersek
2017-08-22  1:42     ` Brijesh Singh
     [not found]       ` <1387174d-0040-0072-5e36-c133fd7ec934@redhat.com>
2017-08-22 14:29         ` Brijesh Singh
2017-08-22 15:53           ` Laszlo Ersek
2017-08-14 11:36 ` [PATCH v2 18/23] OvmfPkg/VirtioScsiDxe: Use DeviceAddresses in vring descriptors Brijesh Singh
2017-08-21 19:08   ` Laszlo Ersek
2017-08-14 11:36 ` [PATCH v2 19/23] OvmfPkg/VirtioNetDxe: alloc Tx and Rx rings using AllocateSharedPage() Brijesh Singh
2017-08-14 11:36 ` [PATCH v2 20/23] OvmfPkg/VirtioNetDxe: alloc RxBuf using AllocateSharedPages() Brijesh Singh
2017-08-14 11:36 ` [PATCH v2 21/23] OvmfPkg/VirtioNetDxe: dynamically alloc transmit header Brijesh Singh
2017-08-14 11:36 ` [PATCH v2 22/23] OvmfPkg/VirtioNetDxe: map transmit buffer host address to device address Brijesh Singh
2017-08-14 11:36 ` [PATCH v2 23/23] OvmfPkg/Virtio: define VIRITO_F_IOMMU_PLATFORM feature bit Brijesh Singh
2017-08-21 15:40   ` 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=72c6cdca-8364-bb2d-227d-30278d9d086a@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