From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: solarflare.com, ip: 67.231.154.164, mailfrom: tpilar@solarflare.com) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by groups.io with SMTP; Fri, 09 Aug 2019 04:13:14 -0700 X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 90C16400082; Fri, 9 Aug 2019 11:13:12 +0000 (UTC) Received: from tp-desktop.uk.solarflarecom.com (10.17.20.51) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 9 Aug 2019 12:13:08 +0100 Subject: Re: [edk2-devel] Capsule PCI device firmware update, could capsule embedded driver override PCI option ROM driver? To: , References: <10206.1565252824023648157@groups.io> From: "Tomas Pilar (tpilar)" Message-ID: <0e90b966-93a9-7bca-5247-5191642a7823@solarflare.com> Date: Fri, 9 Aug 2019 12:13:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <10206.1565252824023648157@groups.io> X-Originating-IP: [10.17.20.51] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24836.000 X-TM-AS-Result: No-14.631700-8.000000-10 X-TMASE-MatchedRID: Z/tjqhsgM6c7iuZ/mdYYtosA1dMVHhEF224ueXqtKLsZXabqA8iZcsyt o8nWOdP/HUF77AOxXpKV4tc/M7dU0fLfqX4QTDm8bHA+DY+LiG8wrAJnuG4aIYNZ82/4ClMEM75 gcJz4AJeLpmW69HlGWErM69p7lDSsguwtqyXlE6FSMUnCl2ZytGwpgekIWIJUzbIX0kjUM7l6Vf tEKMjxFS4YlXCNHMx/F3QLBzDAdyT2X2nyY2WSCcSfo04OTOHo/cXbR0bNRT3fKkJAC3+xQBcMR AKR/nOlISON4rbDxrkfZhFimVQHWxlKjo8zguyKoAktlrw2U4SUV8IkTikQ2LJigbAulEfChLzy Tj+AJsE+D3J+ThgLRpjhZxhC9CTjfiRjGGKYf9sZ+NvfcdGhwdj1awhyfC4Ws1a++a3yZeMY+GY Xlqwk7VJyGi0MYnAfwecYtFTu6LjQUKb7+XI9IKtkcxxU6EVI3Jpgf277KvG5XqtMTiVGzI1KZ8 CNzkV21O4tb6B2RAS84C/3iwAgxCIk3dpe5X+hKkKAvenpKeJ8bVzJ7ca6Kgk3T8rNqp8oPGpJT OvVRmMEaNToh7sIap1U1lojafr/dxtW7Juc34zc9KE2iwgwHnh6u6bomTIVB2cfcVCsIFdF/Psh YHYv2y779nFLSyv7UxXXXFSzt83mIpwQq/SWNgeLCIX046iBzEVDGnc+EfJ5QYjFiDClc9AAI+C 3I6/F1VsVJN4i0I/64QqFNX498W8/sYT3XnwWrMb0wgp4b8aF/eVC4W0tgJu5Bwdm5tTa7c6m8D Q6rNymC/idJMdP2IEU1kn9F/MZRkneFYFnCWmXBXaJoB9JZzl/1fD/GopdWQy9YC5qGvzuDAzQZ mM4YKdghOA+wzEhwrbXMGDYqV8FlVldG0WxKE+CQyKqBtN+dOGrjdhMSOA1zFNvBlRgEWZAIkwh QH/l2ambOY0kHsco4MsJkHan3DLO6egKTUrrzLf8gFu+V4VIlmqkRQfBYA== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--14.631700-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24836.000 X-MDID: 1565349193-doXlrEKOeFvx Content-Type: multipart/alternative; boundary="------------635D053EE34441F01B2B4370" Content-Language: en-US --------------635D053EE34441F01B2B4370 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hi, We also implement capsules to update optionROMs that use an embedded driver in the capsule. The main reason for us is space - crypto library is too large to fit into our flash so we don't provide fully functional FMP in the optionROM driver, only a stub FMP that is enough to populate the ESRT. The spec requires that the embedded driver is loaded by the platform. I would also _expect_ that the platform will try to bind the driver against all devices in the platform using the DriverBinding protocol - this is quite a necessary step for using a driver! I wouldn't expect the platform to unbind the old driver from the device for me, in fact it should not assume it knows the right thing to do here. I implemented this unbinding internally: when my embedded driver loads, it will unbind all (my) existing drivers during the EntryPoint execution. That leaves the controllers free to be bound against using the embedded driver. In fact, if your IHV is writing drivers that are supposed to work in general on other platforms as well, they better not rely on this kind of special behaviour! Caveats: This does potentially cause a problem if existing drivers are very old and buggy and crash the platform during unbinding. It will also leave the controller without a proper driver following the update. This is okay since we expect the platform to reboot following an FMP update. Cheers, Tom P.S. If you put me in contact with your IHV I can explain how I implemented the unbinding on our end. On 08/08/2019 09:27, Lin, Derek (HPS SW) wrote: > Hi, > > I have searched EDK2 devel discussion and Mantis but I couldn't find > answer. > > > Recently we found some PCI card vendor release capsule to update > device firmware. > > Background: > The PCI card has option ROM which provide FMP service. > The capsule has a firmware payload and device driver which also > provide FMP. > > Problem: > The vendor put option ROM device driver into capsule, the only > differences is it is newer version. > The FMP in old PCI option ROM is not functional. > Thus they put a new device driver in capsule, and expect UEFI to > disconnect the old option ROM driver, and connect the new one from > capsule. > > This is different to current EDK2 implementation. UEFI spec 2.8 CH > 23.3.3 define process to handle capsule and embedded driver, it will > call embedded driver's entry point, but won't connect anything. > > Our PCI card vendor is asking to disconnect old option ROM driver, and > connect new driver from capsule. > It makes sense for device vendor to simply provide a device driver in > capsule. > > > Any advice? Do you think it make sense to disconnect PCI option ROM > driver and reconnect capsule driver? > > Thanks, > Derek > --------------635D053EE34441F01B2B4370 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit

Hi,

We also implement capsules to update optionROMs that use an embedded driver in the capsule. The main reason for us is space - crypto library is too large to fit into our flash so we don't provide fully functional FMP in the optionROM driver, only a stub FMP that is enough to populate the ESRT.

The spec requires that the embedded driver is loaded by the platform. I would also _expect_ that the platform will try to bind the driver against all devices in the platform using the DriverBinding protocol - this is quite a necessary step for using a driver!

I wouldn't expect the platform to unbind the old driver from the device for me, in fact it should not assume it knows the right thing to do here. I implemented this unbinding internally: when my embedded driver loads, it will unbind all (my) existing drivers during the EntryPoint execution. That leaves the controllers free to be bound against using the embedded driver.

In fact, if your IHV is writing drivers that are supposed to work in general on other platforms as well, they better not rely on this kind of special behaviour!

Caveats:

This does potentially cause a problem if existing drivers are very old and buggy and crash the platform during unbinding. It will also leave the controller without a proper driver following the update. This is okay since we expect the platform to reboot following an FMP update.

Cheers,

Tom

P.S. If you put me in contact with your IHV I can explain how I implemented the unbinding on our end.


On 08/08/2019 09:27, Lin, Derek (HPS SW) wrote:
Hi,

I have searched EDK2 devel discussion and Mantis but I couldn't find answer.


Recently we found some PCI card vendor release capsule to update device firmware.

Background:
The PCI card has option ROM which provide FMP service.
The capsule has a firmware payload and device driver which also provide FMP.

Problem:
The vendor put option ROM device driver into capsule, the only differences is it is newer version.
The FMP in old PCI option ROM is not functional.
Thus they put a new device driver in capsule, and expect UEFI to disconnect the old option ROM driver, and connect the new one from capsule.

This is different to current EDK2 implementation. UEFI spec 2.8 CH 23.3.3 define process to handle capsule and embedded driver, it will call embedded driver's entry point, but won't connect anything.

Our PCI card vendor is asking to disconnect old option ROM driver, and connect new driver from capsule.
It makes sense for device vendor to simply provide a device driver in capsule.


Any advice? Do you think it make sense to disconnect PCI option ROM driver and reconnect capsule driver?

Thanks,
Derek
--------------635D053EE34441F01B2B4370--