Re: [PATCH kvmtool v2 0/6] arm: Add support for firmware booting

From: Julien Thierry <julien.thierry@arm.com>
To: Will Deacon <will.deacon@arm.com>
Cc: andre.przywara@arm.com, Sami.Mujawar@arm.com,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Subject: Re: [PATCH kvmtool v2 0/6] arm: Add support for firmware booting
Date: Tue, 22 Jan 2019 09:00:01 +0000	[thread overview]
Message-ID: <b5e4bd1c-8bb5-36ca-026e-59fd92a4486d@arm.com> (raw)
In-Reply-To: <20190122071024.GB10214@brain-police>

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,

-- 
Julien Thierry