From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E131D2095B9E0 for ; Tue, 22 Aug 2017 08:50:41 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 51FFF1F58C; Tue, 22 Aug 2017 15:53:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 51FFF1F58C Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-92.phx2.redhat.com [10.3.116.92]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1829E1715B; Tue, 22 Aug 2017 15:53:12 +0000 (UTC) To: Brijesh Singh , edk2-devel@lists.01.org Cc: Jordan Justen , Tom Lendacky , Ard Biesheuvel References: <1502710605-8058-1-git-send-email-brijesh.singh@amd.com> <1502710605-8058-18-git-send-email-brijesh.singh@amd.com> <8392c590-62db-fea9-5cca-aa0e76183c20@redhat.com> <1387174d-0040-0072-5e36-c133fd7ec934@redhat.com> <26532a70-01fb-ddc8-766a-2a0df672f97b@amd.com> From: Laszlo Ersek Message-ID: <7472ba9b-0a3a-caa6-7b19-a9b0f6d32abf@redhat.com> Date: Tue, 22 Aug 2017 17:53:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <26532a70-01fb-ddc8-766a-2a0df672f97b@amd.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 22 Aug 2017 15:53:14 +0000 (UTC) Subject: Re: [PATCH v2 17/23] OvmfPkg/VirtioBlkDxe: map host address to device address X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 15:50:42 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 08/22/17 16:29, Brijesh Singh wrote: > Thanks for detail explanation, I was trying driver unload and reload > from the UEFI shell but that did not trigger the BindStop hence I was > not sure how it all works. *Unload* is a different thing. Clearly a driver can only be unloaded after all its currently bound devices are unbound, but there is no dependency in the other direction -- a UEFI_DRIVER module can perfectly well unbind devices *without* being unloadable. An edk2 driver module that is unloadable specifies the UNLOAD_IMAGE define in its INF file. Pretty few drivers do this. (None of the virtio drivers.) The "Driver Writer’s Guide for UEFI 2.3.1" writes about unloading in "7.6 Adding the Unload Feature" (and possibly elsewhere). > But your explanation makes sense. I will try connect and disconnect > to trigger the code path and make sure that all logical code path > have been tested before we commit the patch :) Sounds good, thanks! Laszlo