public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
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: [edk2-devel] [PATCH v3 13/17] OvmfPkg/PvScsiDxe: Setup requests and completions rings
Date: Mon, 30 Mar 2020 22:46:41 +0200	[thread overview]
Message-ID: <8c97d491-7e0d-986b-d3af-e7b065c5c4ba@redhat.com> (raw)
In-Reply-To: <82d2a754-21cd-9032-b063-7a056775592d@oracle.com>

On 03/30/20 19:24, Liran Alon wrote:
>
> On 30/03/2020 18:54, Laszlo Ersek wrote:
>> On 03/28/20 21:00, Liran Alon wrote:

>>> @@ -509,6 +720,14 @@ PvScsiUninit (
>>>     IN OUT PVSCSI_DEV *Dev
>>>     )
>>>   {
>>> +  //
>>> +  // Reset device to stop device usage of the rings.
>>> +  // This is required to safely free the rings.
>>> +  //
>>> +  PvScsiResetAdapter (Dev);
>> If I understand correctly (at the end of the series):
>>
>> in order to save one of the (ultimately) two reset calls in
>> PvScsiUninit(), namely
>> - one for releasing the DMA buf
>> - and the other (internal to PvScsiFreeRings()) for releasing the
>> rings, you unnested the latter reset call from PvScsiFreeRings(), and
>> added it manually to the error path of PvScsiInit().

> Right.

>> To me, that's more brittle and more difficult to reason about than
>> what I proposed, because now PvScsiFreeRings() does not completely
>> undo PvScsiInitRings().

> Hmm right. Because PvScsiInitRings() also setup the ring to the device
> with a command. Haven't thought about it.

>> I specifically requested that we please not try to save on the two
>> (seemingly) redundant reset calls in PvScsiUninit() -- see the
>> paragraph containing "bad idea" here:
>>
>> [...]
>>
>>      (Note: we could be tempted to somehow "centralize" all of these
>>      Reset operations into a single spot. Bad idea. We are revoking
>>      the device's access rights to different resources, so the
>>      revocation operations will show up in different spots. It's a
>>      mere circumstance that the revocations all happen to be Reset
>>      operations.)
>>
>>      I might be paranoid of course -- I just feel that
>>      maybe-superfluous reset operations on error paths are much
>>      better than silently corrupted guest memory and/or disk
>>      contents.
>>
>> You reacted to that message of mine, but not this paragraph
>> specifically (it was snipped from your followup) -- so I thought you
>> were OK with it. I'm a bit disappointed that you disagreed with my
>> request *silently*.

> Oh now I got what you meant! I misinterpreted it. Not silently ignored
> it of course!
> I can change this in a v4 patch-series if you would like that. Sorry
> for the misunderstanding.
>
> I do agree with your statement that PvScsiFreeRings() is not
> completely an undo of PvScsiInitRings().
> And maybe for making code a little bit easier to reason about, it's
> preferred to just do one additional unnecessary device reset.

>> To summarize: technically, your solution is correct; from a code
>> hygiene and resource ownership question, I'm convinced it is wrong.

> I agree.

>> But, I'll live with it.
>> Reviewed-by: Laszlo Ersek <lersek@redhat.com>

> I can send a v4 patch-series just changing that if you would like.
> Or submit a patch to change it after it will be merged.
> Or that you will change it when applying. Or leave it as is.
>
> I don't have any objection to any of the above.

OK. That's a relief to me, thank you! And I apologize for insinuating
that you deliberately & silently ignored said feedback from me. I tend
to be pedantic about email (it's not natural for me to think that
someone simply missed a comment) -- sorry about that!

Given that I've already merged v3 -- can you please post a followup
patch? Something like:

> diff --git a/OvmfPkg/PvScsiDxe/PvScsi.c b/OvmfPkg/PvScsiDxe/PvScsi.c
> index 0a66c98421a9..3066b83b96fc 100644
> --- a/OvmfPkg/PvScsiDxe/PvScsi.c
> +++ b/OvmfPkg/PvScsiDxe/PvScsi.c
> @@ -1093,6 +1093,12 @@ PvScsiFreeRings (
>    IN OUT PVSCSI_DEV *Dev
>    )
>  {
> +  //
> +  // Reset device to stop device usage of the rings.
> +  // This is required to safely free the rings.
> +  //
> +  PvScsiResetAdapter (Dev);
> +
>    PvScsiFreeSharedPages (
>      Dev,
>      1,
> @@ -1199,12 +1205,6 @@ PvScsiInit (
>    return EFI_SUCCESS;
>
>  FreeRings:
> -  //
> -  // Reset device to stop device usage of the rings.
> -  // This is required to safely free the rings.
> -  //
> -  PvScsiResetAdapter (Dev);
> -
>    PvScsiFreeRings (Dev);
>
>  RestorePciAttributes:
> @@ -1220,12 +1220,8 @@ PvScsiUninit (
>    )
>  {
>    //
> -  // Reset device to:
> -  // - Make device stop processing all requests.
> -  // - Stop device usage of the rings.
> -  //
> -  // This is required to safely free the DMA communication buffer
> -  // and the rings.
> +  // Reset device to make device stop processing all requests.
> +  // This is required to safely free the DMA communication buffer.
>    //
>    PvScsiResetAdapter (Dev);

Thank you!
Laszlo


  reply	other threads:[~2020-03-30 20:46 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-28 20:00 [PATCH v3 00/17] OvmfPkg: Support booting from VMware PVSCSI controller Liran Alon
2020-03-28 20:00 ` [PATCH v3 01/17] OvmfPkg/PvScsiDxe: Create empty driver Liran Alon
2020-03-28 20:00 ` [PATCH v3 02/17] OvmfPkg/PvScsiDxe: Install DriverBinding protocol Liran Alon
2020-03-28 20:00 ` [PATCH v3 03/17] OvmfPkg/PvScsiDxe: Report name of driver Liran Alon
2020-03-28 20:00 ` [PATCH v3 04/17] OvmfPkg/PvScsiDxe: Probe PCI devices and look for PvScsi Liran Alon
2020-03-28 20:00 ` [PATCH v3 05/17] OvmfPkg/PvScsiDxe: Install stubbed EXT_SCSI_PASS_THRU Liran Alon
2020-03-28 20:00 ` [PATCH v3 06/17] OvmfPkg/PvScsiDxe: Report the number of targets and LUNs Liran Alon
2020-03-28 20:00 ` [PATCH v3 07/17] OvmfPkg/PvScsiDxe: Translate Target & LUN to/from DevicePath Liran Alon
2020-03-28 20:00 ` [PATCH v3 08/17] OvmfPkg/PvScsiDxe: Open PciIo protocol for later use Liran Alon
2020-03-28 20:00 ` [PATCH v3 09/17] OvmfPkg/PvScsiDxe: Backup/Restore PCI attributes on Init/UnInit Liran Alon
2020-03-28 20:00 ` [PATCH v3 10/17] OvmfPkg/PvScsiDxe: Enable MMIO-Space & Bus-Mastering in PCI attributes Liran Alon
2020-03-28 20:00 ` [PATCH v3 11/17] OvmfPkg/PvScsiDxe: Define device interface structures and constants Liran Alon
2020-03-28 20:00 ` [PATCH v3 12/17] OvmfPkg/PvScsiDxe: Reset adapter on init Liran Alon
2020-03-30 15:19   ` [edk2-devel] " Laszlo Ersek
2020-03-28 20:00 ` [PATCH v3 13/17] OvmfPkg/PvScsiDxe: Setup requests and completions rings Liran Alon
2020-03-30 15:54   ` [edk2-devel] " Laszlo Ersek
2020-03-30 17:24     ` Liran Alon
2020-03-30 20:46       ` Laszlo Ersek [this message]
2020-03-28 20:00 ` [PATCH v3 14/17] OvmfPkg/PvScsiDxe: Introduce DMA communication buffer Liran Alon
2020-03-30 16:06   ` [edk2-devel] " Laszlo Ersek
2020-03-28 20:00 ` [PATCH v3 15/17] OvmfPkg/PvScsiDxe: Support sending SCSI request and receive response Liran Alon
2020-03-30 16:22   ` [edk2-devel] " Laszlo Ersek
2020-03-28 20:00 ` [PATCH v3 16/17] OvmfPkg/PvScsiDxe: Reset device on ExitBootServices() Liran Alon
2020-03-30 16:23   ` [edk2-devel] " Laszlo Ersek
2020-03-28 20:01 ` [PATCH v3 17/17] OvmfPkg/PvScsiDxe: Enable device 64-bit DMA addresses Liran Alon
2020-03-29  9:29 ` [PATCH v3 00/17] OvmfPkg: Support booting from VMware PVSCSI controller Nikita Leshenko
2020-03-30 16:53 ` [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=8c97d491-7e0d-986b-d3af-e7b065c5c4ba@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