| Message ID | 1547130046-14729-1-git-send-email-julien.thierry@arm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm: Add support for firmware booting | expand |
Hi Julien, On Thu, Jan 10, 2019 at 02:20:40PM +0000, Julien Thierry wrote: > This series is based on the virtio reset series[1] posted earlier. > > We would like to be able to load firmwares like UEFI in kvmtool. > > The series contains: > A way to load the firmware into RAM and an option to be able to create > non-volatile memory zones and load data into them. > > Those non-volatile memory are presented throught the DT with a node: > > <flash>@<addr> { > compatible = "kvmtool,flash"; > reg = < <addr> <size> >; > label = <name>; > } > > These are expected to be dealt with by specific kvmtool driver and not > to be picked up by existing drivers (although technically it is just > plain memory, mapped in the guest). I've picked up the first four patches of this series, but I don't really 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? Will
Hi Will, On 22/01/2019 07:10, Will Deacon wrote: > Hi Julien, > > On Thu, Jan 10, 2019 at 02:20:40PM +0000, Julien Thierry wrote: >> This series is based on the virtio reset series[1] posted earlier. >> >> We would like to be able to load firmwares like UEFI in kvmtool. >> >> The series contains: >> A way to load the firmware into RAM and an option to be able to create >> non-volatile memory zones and load data into them. >> >> Those non-volatile memory are presented throught the DT with a node: >> >> <flash>@<addr> { >> compatible = "kvmtool,flash"; >> reg = < <addr> <size> >; >> label = <name>; >> } >> >> These are expected to be dealt with by specific kvmtool driver and not >> to be picked up by existing drivers (although technically it is just >> plain memory, mapped in the guest). > > 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). Another thing I wanted to avoid would be an existing Linux driver picking up on the "flash device" kvmtool is presenting (don't want it directly messing up with EFI environment). The idea is that you would use this memory only if you explicitly added the support in the software for this platform. EDK2 doesn't already use it (not upstream), but it is part of the support to boot EDK2 under kvmtool series (on the EDK2 side). So, this is not set in stone yet and if you suggestion I can still check with Sami if that works on his side and implement it. Thanks,
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
Hi, This series is based on the virtio reset series[1] posted earlier. We would like to be able to load firmwares like UEFI in kvmtool. The series contains: A way to load the firmware into RAM and an option to be able to create non-volatile memory zones and load data into them. Those non-volatile memory are presented throught the DT with a node: <flash>@<addr> { compatible = "kvmtool,flash"; reg = < <addr> <size> >; label = <name>; } These are expected to be dealt with by specific kvmtool driver and not to be picked up by existing drivers (although technically it is just plain memory, mapped in the guest). Changes since v1[2]: * Added Andre's Reviewed-by tags. * Changed the DT binding for nvmem. * removed the requirement to provide firmware load address (defaults to the start of RAM). [1] https://marc.info/?l=kvm&m=154712959125764&w=2 [2] https://marc.info/?l=kvm&m=154392208726108&w=2 Cheers, Julien --> Julien Thierry (5): arm: Move firmware function builtin-run: Do not look for default kernel when firmware is provided arm: Support firmware loading kvm: Add arch specific reset arm: Support non-volatile memory Sami Mujawar (1): rtc: Initialize the Register D for MC146818 RTC arm/fdt.c | 58 +++++++-- arm/include/arm-common/kvm-arch.h | 5 +- arm/include/arm-common/kvm-config-arch.h | 21 +++- arm/kvm.c | 207 +++++++++++++++++++++++++++++++ builtin-run.c | 24 ++-- hw/rtc.c | 8 ++ include/kvm/kvm.h | 1 + kvm.c | 2 + mips/kvm.c | 4 + powerpc/kvm.c | 4 + x86/kvm.c | 4 + 11 files changed, 317 insertions(+), 21 deletions(-) -- 1.9.1