From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=217.140.101.70; helo=foss.arm.com; envelope-from=jeremy.linton@arm.com; receiver=edk2-devel@lists.01.org Received: from foss.arm.com (foss.arm.com [217.140.101.70]) by ml01.01.org (Postfix) with ESMTP id 37F432034AB0C for ; Mon, 30 Oct 2017 16:06:18 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A24131529; Mon, 30 Oct 2017 16:10:08 -0700 (PDT) Received: from [192.168.229.136] (unknown [10.118.28.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 05A453F3E1; Mon, 30 Oct 2017 16:10:07 -0700 (PDT) To: Udit Kumar , Ard Biesheuvel Cc: "edk2-devel@lists.01.org" , Andrew Fish , "Olivier.Martin@arm.com" , Vladimir Olovyannikov References: <4CC33CC2-86D1-490E-A67E-12D751745121@apple.com> From: Jeremy Linton Message-ID: <48c3e611-0e17-2014-b0fe-fca58393b975@arm.com> Date: Mon, 30 Oct 2017 18:10:06 -0500 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: Subject: Re: Storing Non volatile variables on SD/NAND 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: Mon, 30 Oct 2017 23:06:18 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Hi, On 10/27/2017 10:09 PM, Udit Kumar wrote: >> (along those lines) >> >> 6 - Build an emulated disk controller as well as NV region in el3 (or >> el2) and export them to UEFI & the OS as real devices. Then trap/forward >> requests to the actual storage device, which is "hidden". This AFAIK was the >> basic idea behind the PS/2 emulation in x86/SMM. Again, probably not a high >> performance option. > > You mean, have a driver in el3 or el2 and UEFI or OS is doing smc call to get things done. > On this line, some sort of permission manager could reside in el3 or el2. > Either UEFI or OS driver needs to make a call, if they are allowed to access this > specific controller or other driver is accessing it. > With this performance issue could be ironed out . That isn't really what I meant, what I was thinking about was creating an emulated (AHCI for example) controller where accesses to the "register" space would trap to synchronous data/external aborts. That way the firmware and OS could use existing drivers without knowledge that the device was in any way special. If you create a driver and do SMC/whatever calls, then your basically doing #5.. > > Regards > Udit > >> -----Original Message----- >> From: Jeremy Linton [mailto:jeremy.linton@arm.com] >> Sent: Friday, October 27, 2017 11:16 PM >> To: Ard Biesheuvel ; Udit Kumar >> >> Cc: edk2-devel@lists.01.org; Andrew Fish ; >> Olivier.Martin@arm.com; Vladimir Olovyannikov >> >> Subject: Re: [edk2] Storing Non volatile variables on SD/NAND >> >> On 09/20/2017 12:39 PM, Ard Biesheuvel wrote: >>> On 20 September 2017 at 10:34, Udit Kumar wrote: >>>> >>>> When we want to have UEFI and OS accessing same media , Possibilities >>>> I see >>>> >>>> 1- Patch OS For status check of media (diversion from generic OS), Good case >> will be modify low level driver. >>>> But we may end up some surprises on synchronization. >>>> >>>> 2- no runtime service for OS . I guess this will not be possible >>>> >>>> 3- Way the Vladimir implemented for eMMC, This has risk of losing data in >> case of AC power off. >>>> >>>> 4- update hardware with dual view (Ard suggestion) >>>> >>> >>> 5 - abstract direct block device access into a firmware service that >>> is exposed via a DXE_RUNTIME_DRIVER. >> >> (along those lines) >> >> 6 - Build an emulated disk controller as well as NV region in el3 (or >> el2) and export them to UEFI & the OS as real devices. Then trap/forward >> requests to the actual storage device, which is "hidden". This AFAIK was the >> basic idea behind the PS/2 emulation in x86/SMM. Again, probably not a high >> performance option. >> >> >>> >>> The UEFI spec allows you to expose entry points into a >>> DXE_RUNTIME_DRIVER module via a UEFI configuration table, and the OS >>> can use a driver that uses the abstracted device rather than the real >>> device. Performance is going to be terrible, probably, and lots of >>> things that are specific to SD/MMC will no longer work, but it is a >>> possibility nonetheless. >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01 >> .org%2Fmailman%2Flistinfo%2Fedk2- >> devel&data=02%7C01%7Cudit.kumar%40nxp.com%7Cfe11f07ea67a4efa7d1b08 >> d51d629deb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63644723 >> 1755528994&sdata=FYnH3ItGhXmqxNr%2BnaJBFMcKKduf%2FcS06JEA6dT6ZQA >> %3D&reserved=0 >>> >