Messages in this thread | | | Date | Wed, 18 Nov 2020 09:25:47 +0000 | From | Quentin Perret <> | Subject | Re: [RFC PATCH 15/27] of/fdt: Introduce early_init_dt_add_memory_hyp() |
| |
Hi Rob,
On Tuesday 17 Nov 2020 at 13:44:53 (-0600), Rob Herring wrote: > Can this be done right after we add all the memblocks using the > memblock API?
Possibly, but the thing I'm a bit worried about is the way 'no-map' regions are removed from memblocks early on.
The EL2 object needs to know about these parts of memory too (and in fact we may be able to enforce the 'no-map' attribute at the host stage 2 level as well). It's also possible we'll need to have portions of the guests payload preloaded (and verified) by the bootloader into reserved memory regions, possibly no-map, to make sure the host does not mess with them in a normal use-case. So, I couldn't find a much better place than this one but suggestions are very much welcome.
I'll have a go at the memblock stuff to see if I find a way to make it work from that angle.
> I thought EFI would also need to be handled, but looks > like it just calls early_init_dt_add_memory_arch(). That's odd > especially for ACPI systems... > > I don't really like putting what looks like an arm64 only hook here, > but then I don't want an arm64 version of > early_init_dt_add_memory_arch() either. We're almost to the point of > getting rid of the arch specific ones. But I don't have a better > suggestion currently.
Ack, the ugly truth is that this is likely to remain arm64-specific. I figured this was simple enough that we might want to consider it, though.
Thanks, Quentin
| |