public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>, devel@edk2.groups.io
Cc: Jordan Justen <jordan.l.justen@intel.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Julien Grall <julien.grall@arm.com>
Subject: Re: [PATCH] OvmfPkg/XenBusDxe: Don't call DisconnectController in Stop()
Date: Mon, 1 Jul 2019 16:39:42 +0200	[thread overview]
Message-ID: <9f384863-60e4-efec-0f95-e61434469292@redhat.com> (raw)
In-Reply-To: <20190701111403.7007-1-anthony.perard@citrix.com>

On 07/01/19 13:14, Anthony PERARD wrote:
> Calling DisconnectController() on children isn't part of the job of
> EFI_DRIVER_BINDING_PROTOCOL.Stop() as it only needs to deallocate
> resources allocated in Start(). The disconnection will happen when
> both DevicePath and XenBus protocols gets uninstalled.

Correct. In the spec, UninstallMultipleProtocolInterfaces() refers to
UninstallProtocolInterface(), and the latter says,

    [...] Before the protocol interface is removed, an attempt is made
    to force all the drivers that are consuming the protocol interface
    to stop consuming that protocol interface. This is done by calling
    the boot service EFI_BOOT_SERVICES.DisconnectController() for the
    driver that currently have the protocol interface open with an
    attribute of EFI_OPEN_PROTOCOL_BY_DRIVER or
    EFI_OPEN_PROTOCOL_BY_DRIVER | EFI_OPEN_PROTOCOL_EXCLUSIVE. [...]

And, the Driver Writer's Guide states, in a Note,

    When an attempt is made to remove a protocol interface from a handle
    in the handle database, the UEFI core firmware checks to see if any
    other UEFI drivers are currently using the services of the protocol
    to be removed. If UEFI drivers are using that protocol interface,
    the UEFI core firmware attempts to stop those UEFI drivers with a
    call to DisconnectController(). This is a quick, legal, and safe way
    to shut down any protocols associated with this driver's stack.

> 
> Reported-by: Laszlo Ersek <lersek@redhat.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> 
> Notes:
>     Please apply this patch after:
>     "OvmfPkg/XenBusDxe: Close XenIoProtocol openned by children"
> 
>  OvmfPkg/XenBusDxe/XenBusDxe.c | 6 ------
>  1 file changed, 6 deletions(-)
> 
> diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.c b/OvmfPkg/XenBusDxe/XenBusDxe.c
> index 7c07a96650..634c7b71eb 100644
> --- a/OvmfPkg/XenBusDxe/XenBusDxe.c
> +++ b/OvmfPkg/XenBusDxe/XenBusDxe.c
> @@ -446,12 +446,6 @@ XenBusDxeDriverBindingStop (
>        continue;
>      }
>      ChildData = XENBUS_PRIVATE_DATA_FROM_THIS (XenBusIo);
> -    Status = gBS->DisconnectController (ChildData->Handle, NULL, NULL);
> -    if (EFI_ERROR (Status)) {
> -      DEBUG ((EFI_D_ERROR, "XenBusDxe: error disconnecting child: %r\n",
> -              Status));
> -      continue;
> -    }
>  
>      Status = gBS->CloseProtocol (Dev->ControllerHandle, &gXenIoProtocolGuid,
>                      Dev->This->DriverBindingHandle, ChildData->Handle);
> 

Reviewed-by: Laszlo Ersek <lersek@redhat.com>

  reply	other threads:[~2019-07-01 14:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-01 11:14 [PATCH] OvmfPkg/XenBusDxe: Don't call DisconnectController in Stop() Anthony PERARD
2019-07-01 14:39 ` Laszlo Ersek [this message]
2019-07-01 14:56 ` 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=9f384863-60e4-efec-0f95-e61434469292@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