lkml.org 
[lkml]   [2020]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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

    \
     
     \ /
      Last update: 2020-11-18 10:27    [W:4.550 / U:0.684 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site