From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0047.outbound.protection.outlook.com [104.47.33.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B3DBA21E49BAB for ; Tue, 22 Aug 2017 07:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amdcloud.onmicrosoft.com; s=selector1-amd-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uz+/mNFOtaVhTQaARMYJv08ci+doC9IuKX2cjz5/up4=; b=UN7JmvMv2A72SZwqhyWwM7aV/uPefRmtxf3YD4XYR3qsfdqXASMMkb9PiX4c47EoWFGon5lejtMUgLjUM1K3HhGg5rZw0lUmyhD6AqpSrUc+lxKBWdbfd8SXUR1948X9/z4UPutxqogPQ0fen6FEnzDtMTel3F46v8+ZKol+iow= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=brijesh.singh@amd.com; Received: from [10.236.136.62] (165.204.77.1) by DM2PR12MB0156.namprd12.prod.outlook.com (2a01:111:e400:50ce::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1362.18; Tue, 22 Aug 2017 14:29:51 +0000 Cc: brijesh.singh@amd.com, Jordan Justen , Tom Lendacky , Ard Biesheuvel To: Laszlo Ersek , edk2-devel@lists.01.org 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> From: Brijesh Singh Message-ID: <26532a70-01fb-ddc8-766a-2a0df672f97b@amd.com> Date: Tue, 22 Aug 2017 09:29:47 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1387174d-0040-0072-5e36-c133fd7ec934@redhat.com> X-Originating-IP: [165.204.77.1] X-ClientProxiedBy: MWHPR06CA0006.namprd06.prod.outlook.com (2603:10b6:301:39::19) To DM2PR12MB0156.namprd12.prod.outlook.com (2a01:111:e400:50ce::19) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 826e84aa-d1a3-4916-6338-08d4e96a407a X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR12MB0156; X-Microsoft-Exchange-Diagnostics: 1; DM2PR12MB0156; 3:xrhM260i19Epgz0jnMdxLfBkovRJ1NO0qu/2LN2s/KycY7l8VmrEpBlDduV0mG2J5jv0IaHJ9pmN1qsBJYhldRjd3Ngseg1domp9rOKHnqFuIoOURIvldtpsKvOoiHbUQitMVh8+95SEjyivEyLx5Iy/l1acy4Q8jX3qHIoB358Wa7Ph/nYGKnphn4R4sXZlFxue0+/Fx1/UT+ZW2Zj4feitwPB5XqywX3zgcMBdq9V3jPZnmrEFVJX+YrUe1WV1; 25:oJJH+Tend1PoPvakWRzYPxeBGTFpl3gDzbHTovW/3LMukZ76i+3Gf+hY2XRzf7nHdALkYpSoBHJkY52jmzY6+OI8BefGx/FZlAYsKQp39+Mw/lpZ6kx5P5An+9nqG+9svE2TZMEKwxIu3lnv0eNW0GZt2F5djaE6Qfa1b0AgtI1UBoAb5A+hw20Jl5DwGLlJI16yn3tCBRZd+GfgSMcyawFcg5j6rVjcfVQ7RNFrhAUOxY23jMEuZ+eXLenUi1II03wYlJZeuTtXZl9johRBV29zyUEqhfAfO9XGFVxVFQJzYdcU7qv5fmva7VzSHatnv2RE28KEjKCWiRkbtGBTUw==; 31:R/tnMnWZmDXYW8pZ+H5uwACZumUrn14kv2gPo0uI7ozwkHnT0TCjIQt2GL2uhfasQl7WbgwV5UkMjM+3kpSgyD1baTJQKlURcdOarC97GLKzTj/Yk/eZ3pqJQfH2rG6WfcReg4K5Vj+I+QHJpcBU36jH+9vwq3WrvUcuSXOociz46pYeDjNh7bX1QuiirZwxua/kDWTA921KWz7AOGDMsTe/hH9IQ0CI2R6k6BQXq7Y= X-MS-TrafficTypeDiagnostic: DM2PR12MB0156: X-Microsoft-Exchange-Diagnostics: 1; DM2PR12MB0156; 20:fLu17oMqptlt7SkTaDMB/rUS4zO2LFmuGihUXfOimwMWZTpijaphOIKWW0ZgurgQsaGSvzBxR8QVzzT2yfNiGp/05YUOxb7o6c5bRqsSoybm5TJmN+S3WGa+hhceqCPNC9TlbjPy0HI0Za74uuFcVesI5vApYTB2INQplZ556eMnwa/EJdNsqe5WdpNRDD3RdY/+KJqESCaaDAwYu6l1iVMY2NNEQkPBk01h0UIRN0zeJ8GWfmyBpBVPdlrbb+0nB/d8sewCv9sTzYsBwdB+YrHwa2RY69e/NYfyDp+GqTpbGD/HPn6Y6cqLeBACvKpP5xO9tXPYrav2AKq6XpT5xDymsiB13YrKZVO9C7KY0Aqu8kDLge+Z+lyHVFsu4bW+TwLp4R+kd8XWQEE3gOpbINmp62fTKOqJucjjE0n3N1XoxE0Yy80cfbJTHd9knjHYxG3WEOg66LhabS99mV0ZZah7zOsI2l13LM7XbxYOBP/I8XCRwnLJwLTKxDp/tC4E; 4:wg5x9qBsf4xE8wZ8XXJLNS2IFERYky8P54DxCsryqr2RLj3bfuWrAhvM7eq/Oby8MUlDThUH5D0NUDRUlU46qGtgpv4AGpdCz0KNoZi55ohdmEiZS0sN3CrRhHr2sAuNOJK5emMI5gTpoMN0ecBMK1w5ifwpuK+rr6OXaC4y3y8DskRRr+eMBJ2PeyFj5ci22a6dZ98jHR/QlNykxXOBgsOK8rQN5tAGvlyYCweUGtg9PI3pmdlLZlICtwtSmNyTRrGeTN4lEH5pdNr7gQHP8Rfs9zYjB4JbqMx6IAkOUFQ= X-Exchange-Antispam-Report-Test: UriScan:(21532816269658); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR12MB0156; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR12MB0156; X-Forefront-PRVS: 04073E895A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(7370300001)(6049001)(6009001)(39860400002)(199003)(24454002)(189002)(377454003)(5660300001)(54906002)(97736004)(47776003)(4001350100001)(64126003)(305945005)(65826007)(110136004)(93886005)(7736002)(4326008)(7350300001)(105586002)(53936002)(86362001)(50466002)(6486002)(6246003)(83506001)(68736007)(77096006)(76176999)(2950100002)(6666003)(101416001)(8676002)(54356999)(6116002)(50986999)(230700001)(106356001)(478600001)(229853002)(81166006)(81156014)(65956001)(65806001)(42186005)(66066001)(53546010)(31686004)(31696002)(33646002)(36756003)(25786009)(189998001)(2906002)(3846002)(23676002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR12MB0156; H:[10.236.136.62]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: amd.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTJQUjEyTUIwMTU2OzIzOjJ1amlGbUtjR1hhL1gyRG5pOXJaSE1wNDFM?= =?utf-8?B?aC9BRmo5VzIyT25VUGNZWm9Ed3BYSHBSbVdRcU5qRVN5UWlPNHNUczZuUWJP?= =?utf-8?B?TXU4dmVzMlZQeVdzZnF2NHdoQUpuVE9VL0UzRVFVVjBObHRVRis0Q3N5NFQz?= =?utf-8?B?dTJId0FLajZiaDhxaVJMbjdlUzJsWURCZHFDUXRPckp2UDJYWFIyVXFKR3VF?= =?utf-8?B?RUdJM3ZGUUd4RWQyVlFVS29YdWw5OWlsdmpNRStHK1F3WkUrNWcvWVViZWNi?= =?utf-8?B?cFFBdGREd3hISDBJd21URlJRdzRpT3dHMXpvN1FMOXZRVEZYS280cjRDbFpy?= =?utf-8?B?S2h5OXNEbzFYejRzamQvYlpYVWJldXAxMWxFTjZMRUt1M0VQcGY2aWVBWnNr?= =?utf-8?B?Ny9yRU8wOVlKRXkyRVZEVkhma3NTK0Zidy9EOGhnaThDZlFjN2toUGRwSjJO?= =?utf-8?B?OE5jRmgrS3Q1U1BQQmdUcnlNb2VOK1J3R3VEV0t0UHhraWliSDMwYjRjMUlE?= =?utf-8?B?ZFZvTDBOLzA5TlJ3eWRxbFRnVHZvS1p1cjRLa2Jzbm4zQmh4akJRR2tzVGk0?= =?utf-8?B?UnpKcFNsMS9kZHc5QlRMNS9PWHJleGFIU0dvd3owLytTYzNTdnkyV0lEaSt3?= =?utf-8?B?VWJwUFJMVDlFTG8wUVJDaTBWTWNaOTU2R3hJWXZNcVhOSVkyQzhac210aVpn?= =?utf-8?B?ZlBlNThSaWhTdnB1TlpRSFZFUHdVUzBleE5jeUFnTlpNYkhFM0xUcWlBcXNU?= =?utf-8?B?aUdpNlBERWo2eVVCZ3hYTS9jZ2xNaUhVdVRUczVhQXpidENqNHYzcWdrcUg3?= =?utf-8?B?S0NPWERRRktmait0WnM1SnoxSTBLUjFQUDJPK3JGclZQSTIwdTBNSSs4Vld4?= =?utf-8?B?UGVBL0V0T0V2Wk9FSmt6eXhHTlhOaGpJdGppR0ZqL04rK1dkTkw1ejR4V2dI?= =?utf-8?B?NFpSbkhmUWRDV0Z6UHhVK3V6SFdJUmZjUDBLQTdRVTg5VGpXbHFNRzNaT29v?= =?utf-8?B?VXE4Z0pPWDFkRWZscndZSm9rTjBxL3NDM0RicUdhcHdWaXgvYTNRMkFVMUJM?= =?utf-8?B?cGxqWEloSkd3WDR5YnBHWG5FZFRkUWxzSkdYV0hvUktjMW5yUCs5WGhCQ2pU?= =?utf-8?B?ZHIvNkQzcmdmWGdPZ0hjZUNqQjlIalVmVDhRRHNrTWxvWk1ibXcxclkyOG9j?= =?utf-8?B?Y0lDb0Q2QVdmbWx0djBEUlNnK2JNYTFKSnQ4TXk2OEpRTHBrdFQ4cGdiOWVo?= =?utf-8?B?dGdZaXZwYjZwWnk1RFovYVU5M3NaZGNFdGVtT1hKOUp4MVpKQ2kybnlmU0VP?= =?utf-8?B?VFREWUxIMTdYSkFnT2Nodk5qNFdSeERTZ0c3Z0oybmYvZ3JNNFo0WS9rUmo5?= =?utf-8?B?akkrTERsVmJNTm1EaG5tc3VCWkRJZjM1clFzUVRpVEg5OWFkTW8zcHdEOE5p?= =?utf-8?B?OUJINm12ai9lM2s5Wm5qUDNFT2lUSVRQT0NxNEpWcW5vdExFRi94dzdjZUhl?= =?utf-8?B?U1lENGJQRlRMK1ZDMFpmNVpFVjRaZUo0R2xSMkt0UDNFdE15cWNpTmJSOTJt?= =?utf-8?B?ckNyai92VlQzZVo1UkxUdDdHZmRQR1NwMVIyTXlCelR0N0thUFpaRXJsT1Z4?= =?utf-8?B?MmFMSG9XZW1iRGg1TkJPYVBUSnJhcjhKOWYvY1lFQnRjVm9UUXhQUjlTZFJY?= =?utf-8?B?UlhtQ3NpbS9QUVh5Z1NNdlRVdkoxOURHUWlwcGV0T2RIMmVjTlpQMFZYcVZ6?= =?utf-8?B?REZ2YWhqRXF1K21oc1ZQak9GOUZEMzNSTUxCS1JORDN3SlVXTDRpSEhFMXFW?= =?utf-8?B?Z1ZaZExOOEVBMWcrTUpaSWlZczIzaGVlcXVOekdLTUZVUWZ2aU5SZ1cxSkpL?= =?utf-8?B?SzZ6MVJiUEY0UDZaYlp5SnJsc2pGcTMwc2hnUGY1QXlPM0ZHUzczcVdHR0dj?= =?utf-8?B?S1J0NDdxdkxBPT0=?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR12MB0156; 6:8IsS188+0GcArKc2AqzDGIk2ipFOutClTPT52kMHrCKQXOnWZuFss2oVs0OjbxR+frJsLDO54ZmsP7Nm7eXlu028vmLC6yxYTH89bvFa49fRld2ehKejyPM3e8f466r+ELTGWzko3M4ZerlVaWQsdXXjXWlLnvwdiog/vLKKY+b5yVCk8YuqTmFSPmg+HuO3egW3qZEQbVNaf5uKOqkwhwWXaC/+cq2AW/D5RXgtP96ygLEtxpwNwXj/S4orlUbtzvuzRPmpRnFJxAax5iO8FUBPwAhEjb95GYcDJsBXNVHGfR1yjGP4Xgs4Etl7qmW5HC/KPQp/F2KjEcOnKvb/jQ==; 5:EEppfwBhoZIjHntZcirGyQQ9Z6vjMkfF1ev3lHd3HAujOXEC/WxfIiMnx8agNeOzBaizpomMm5BQygUN6VVjs1jCQAH4D1hKF9ASHsAofHZvzmsKglQ2YhYw9esA90MmGWzQPQ6LlcN7V2hzl8r9kg==; 24:ezG9g5GFGMfDkgo93fWG+5gW1CPRgqcJ8VEcZIUsIgbmsho6pk+pnYTNEdbIlwXVEYai1LBjD58KSNB9ZLoOkicPtfCAk222/6v0BPFc6xc=; 7:iB790iTF32q6KFseVLRY0sFFlDWgd56AmM1Mwx7S1q8Ode8GtVPNJW3opQvuyEP8zg6IBZRfzEqfwt+EnbPFzHWzTV8N6au8FQNhZ6S9xzESwN2DL1NxjAKwlMzdOzmWXgxvR2av06MqSZ8im0DQL2bUjwyioJiqI6g6pb8SpQxiPqaHNtmToaQyGzz6h/J+BChZMl94i3eXUF0ngcZBbJY7ntBXOWUuSE/wnnFv6Wk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM2PR12MB0156; 20:U1MMYfnvaCzNGsSQZ+coyy55plHEgngqv1mjx3TEODjS9jWLk3CcIWKziZLsuMaQoq24AOisv3jgQIxac3TgAOPi5iEoUIHRIoi4/zoBSJ6N1PFwIdI2wjHipeL3O4Yeklka2dGHwmeDs5uGfkef3PJ1eWIda93etk92s5TXJ9m65u6GRL7TzHztedzcKnqPoPz0GtZqJGmYDj53ZJI9iPz7GDZ6RL0qPzmNhopA+qLGcziaX34nz760sbyvklyx X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Aug 2017 14:29:51.4587 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR12MB0156 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 14:27:23 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Laszlo, On 08/22/2017 06:14 AM, Laszlo Ersek wrote: > >> So the question: is it possible that we may get called from both >> ExitBootService notify and device uninit functions ? > > This is a valid problem statement / question, and I verified your code > with regard to it, in the patches that I reviewed. > > Let's use VirtioBlkDxe as an example: > > (1) The VirtioBlkDriverBindingStart() function calls VirtioBlkInit(). > > (2) If, and only if, VirtioBlkInit() returns with success, then the ring > has been mapped. > > (3) If, and only if, VirtioBlkInit() has returned with success, then we > create the Dev->ExitBoot event (EVT_SIGNAL_EXIT_BOOT_SERVICES) in > VirtioBlkDriverBindingStart(), the notification function being > VirtioBlkExitBoot(). The task priority level at which the notification > function will be enqueued is TPL_CALLBACK (just above TPL_APPLICATION). > > (4) If the protocol interface installation fails in > VirtioBlkDriverBindingStart(), then the Dev->ExitBoot is closed first > (which unregisters the notification function), and VirtioBlkUninit() is > called second (more on this below). > > (5) Side topic: > > According to "Table 23. TPL Restrictions" in the UEFI spec v2.7, > ExitBootServices() may only be called at TPL_APPLICATION. This means > that the notification function will actually be executed before > ExitBootServices() returns. > > I'm only mentioning this because in some cases the installation of a > protocol interface has to be done very carefully. Some other module may > have set up a protocol notify e.g. at TPL_CALLBACK. If the driver > installs the protocol interface at TPL_APPLICATION (the default), the > protocol notify in the other driver may be invoked immediately, and that > driver might call back into the first driver, in order to use the > just-installed protocol. This requires that the first driver either > raise the TPL temporarily (so that the protocol installation not result > in an immediate notification in the other driver), or make sure that the > protocol being installed be immediately usable. > > With regard to ExitBootServices() however, this is irrelevant. Any > protocol install notification function invoked like above runs at > TPL_CALLBACK, or at a higher task priority level. Therefore it *must > not* call ExitBootServices(). > > Which, ultimately, guarantees that our BlockIo installation in > VirtioBlkDriverBindingStart() will never result in a direct callback to > VirtioBlkExitBoot(). > > (6) Now consider VirtioBlkUninit(). With the feature in place, > VirtioBlkUninit() both unmaps and frees the ring. It is called from two > contexts: (a) when we get "far enough" in VirtioBlkDriverBindingStart() > but then fail ultimately (see point (4), and the label "UninitDev"), and > (b) when the binding succeeds just fine, and then later the driver is > asked to unbind (disconnect from) the device -- in > VirtioBlkDriverBindingStop(). > > In VirtioBlkDriverBindingStop(), we close Dev->ExitBoot, before we call > VirtioBlkUninit() and unmap the vring. Closing the event deregisters the > notification function, and also clears any invocations for the notify > function originally enqueued via this event. > > (FWIW, I don't see how any such invocations could be pending here, > because that would imply that some agent called *both* > ExitBootServices() and our VirtioBlkDriverBindingStop() at a TPL higher > than TPL_APPLICATION -- it would be totally invalid. Nonetheless, this > is how closing an event works.) > > > The upshot is that three scenarios are possible: > > - VirtioBlkDriverBindingStart() fails. On return from that function, the > vring is not mapped, and the exit-boot-services callback does not exit. > > - VirtioBlkDriverBindingStart() succeeds. On return from the function, > the vring is mapped, and the exit-boot-services callback is live. Then, > the driver is requested to unbind the device > (VirtioBlkDriverBindingStop()). The callback is removed, and the vring > is unmapped in VirtioBlkUninit(). If ExitBootServices() is called > sometime after this, then the callback is not there any longer. > > - VirtioBlkDriverBindingStart() succeeds. On return from the function, > the vring is mapped, and the exit-boot-services callback is live. Then, > ExitBootServices() is called. VirtioBlkExitBoot() runs, resetting the > virtio device, and unmapping its vring. VirtioBlkDriverBindingStop() may > never be called after this point, because boot services will have been > exited after all the callbacks run and ExitBootServices() returns. > > > In general ExitBootServices() notify functions behave very differently > from BindingStop() functions. The latter tear down all the structures > nicely, in reverse order of construction, freeing memory, uninitializing > devices, and so on. In comparison, the former *must not* free memory, > only abort in-flight transfers and de-configure devices surgically, > "in-place", so that they forget previous system memory references. These > two are exclusive. > > When people first write UEFI drivers that follow the UEFI driver model, > they are tempted to call (or imitate) the full BindingStop() logic in > the ExitBootServices() notify function. That's wrong. Those contexts are > different with regard to system memory ownership. In BindingStop(), the > memory is owned by the driver. In the ExitBootServices() callback, the > memory is already owned by the OS (sort of), it is only on "loan" to the > driver -- after which a call to BindingStop() is impossible. > > > Therefore the answer to your question is, "no, that is not possible". > >> If so, then we will >> have issue because now we will end up calling Unmap() twice (once from >> ExitBootServices then device uninit). In my debug statement I saw the >> call to ExitBootServices but was never able to trigger code path where >> the device uninit is called. > > If you had been able to trigger such a sequence (exit-boot-services > callback followed by BindingStop), that would imply a huge problem in edk2. > >> I am wondering if you know any method to >> trigger the device uninit code flow so that I can verify both the path. > > Testing repeated BindingStart / BindingStop calls is indeed a good idea > -- sort of necessary -- for any UEFI driver that follows the UEFI driver > model. It's easiest to do with the CONNECT, DISCONNECT and RECONNECT > commands in the UEFI shell. (Please see their documentation in the UEFI > shell spec.) > > In order to find suitable handles for testing (driver and device > handles), I recommend the DEVICES / DRIVERS / DEVTREE / DH commands. > Personally I find DH the most useful, in particular with the "-d -v" and > "-p" options. > > For example, "dh -d -v -p BlockIo" should give you a detailed list of > handles with BlockIo protocol interfaces on them, and the output should > help you find the ones installed by VirtioBlkDxe. > > Sorry about the length of this email (I realize a shorter email might > have been more to the point). I hope it helps a little. > 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. 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 :) -Brijesh