On Tue, Jan 22, 2019 at 09:00:01AM +0000, Julien Thierry wrote: > On 22/01/2019 07:10, Will Deacon wrote: > > I've picked up the first four patches of this series, but I don't really > > Thanks! > > > understand where you're going with the non-volatile memory part and whether > > it's nvram, flash or something completely different. Given that Linux > > doesn't support your binding, is this something that UEFI currently uses? > > > > So the thing is that UEFI/EDK2 needs some kind of readable and writable > non-volatile memory (flash or nv-ram, not sure what's the difference) to > load/store its environment. For kvmtool, we can just provide memory > region where the environment is mapped and EDK2 can just directly read > from or write to it. > > The thing is, when looking at the flash binding in Linux, each platform > seems to have its own binding of their flash device (Which I guess makes > sense since they don't necessarily work the same way). I couldn't find > any existing generic bindings that seemed to fit what I'm presenting to > EDK2 (which could also be used by another firmware if they needed a > binary blob in flash or something). We could probably abuse memreserve for this, which I think happens in the wild already for non-memory regions. However, if the non-volatile region is outside of ram, then why do we care at all? Is UEFI parsing the dts to locate it? If so, I'd have thought that they would need to get a binding sorted for that purpose, in which case we can just use that. Will
