Re: VMA merging updateds?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2024-09-30 at 09:05 +0100, Lorenzo Stoakes wrote:
> > So I get on this first and come back to this lore thread later when
> > I have some more experience on the topic.
> 
> OK cool let's revisit this when you've done that.
> 
> I think if you did want assistance from VMA merging what I delineated
> above
> is the only sensible way forward, afaict.

So I did run some tests and since a TEE (trusted execution environment)
needs in all cases idea what it expects kernel to do all TEE's need a
memory manager. Enarx is multi-arch, and in the case of SGX there is
permissions bits per page owned by the enclave, on VM based confidential
computing (such as AMD SEN-SNP) there's some other weird shenanigans but
across all arhitectures there exists a constraint, which causes the
need. I.e. whatever happens in mm in kernel side cannot simplify the
implementation.

The current implementation of Enarx does not merge but I did some
experimental change doing "munmap and mmap" dance and I don't see
any mentionable change in the benchmarks.

So I came from the wrong early assumptions and made wrong conclusions
in the first place, i.e. somehow this mmledger crate could rendered
out. Had not looked at the code base either for 1.5 years but should
have started what I've now done first in order to recall all the
consraints.

BR, Jarkko





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux