Memory ARM:我的ARM虚拟机监控程序相对于Linux/Android客户机的安全物理内存位置(保留)

Memory ARM:我的ARM虚拟机监控程序相对于Linux/Android客户机的安全物理内存位置(保留),memory,linux-kernel,arm,hypervisor,reserved,Memory,Linux Kernel,Arm,Hypervisor,Reserved,我正在ARM上开发一个基本的虚拟机监控程序(使用Arndale Exynos 5250板)。 我想加载Linux(ubuntu或smth-else)/Android作为来宾。目前我使用的是Linaro发行版 我就快到了,除了最后一个问题外,大多数大问题都已经解决了:为我的虚拟机监控程序保留内存,这样内核在解析FDT或内核命令行之前不会试图覆盖它 问题是,我的Linaro发行版的U-Boot将R2中的FDT传递给linux内核,但是内核在看到我在FDT中保留了该内存区域之前尝试覆盖我的虚拟机监控程

我正在ARM上开发一个基本的虚拟机监控程序(使用Arndale Exynos 5250板)。 我想加载Linux(ubuntu或smth-else)/Android作为来宾。目前我使用的是Linaro发行版

我就快到了,除了最后一个问题外,大多数大问题都已经解决了:为我的虚拟机监控程序保留内存,这样内核在解析FDT或内核命令行之前不会试图覆盖它

问题是,我的Linaro发行版的U-Boot将R2中的FDT传递给linux内核,但是内核在看到我在FDT中保留了该内存区域之前尝试覆盖我的虚拟机监控程序的内存(通过反编译DTB、修改DTS并重新编译)。我试图更改内核命令行参数,但在内核试图覆盖我的保留内存部分后,它们也会被解析

因此,我需要的是在物理RAM中有一个安全的内存位置,用于放置虚拟机监控程序的代码,这样Linux内核在解析FDT或其内核命令行之前不会尝试访问(r/w)它

上下文详细信息:

  • Exynos 5250上的系统RAM布局为:物理RAM从0x4000_0000(=1GB)开始,长度0x8000_0000(=2GB)
  • linux内核(通过U-Boot)在0x4000_7000处加载,其大小(未压缩的uImage)小于5MB,其入口点设置为0x4000_8000
  • uInitrd0x4200_0000处加载,大小小于2MB
  • FDT(board.dtb)加载在0x41f0_0000(在R2中传递),大小小于35KB
  • 我当前在0x40C0_0000加载我的虚拟机监控程序,我想从该地址开始预留200MB(0x0C80_0000),但内核试图在那里写入(第2阶段的HYP陷阱告诉我这一点)在FDT或命令行中查看区域是否实际保留之前。相反,如果我在0x5000\u 0000加载虚拟机监控程序(甚至不修改原始DTB或命令行),它不会试图覆盖我
  • FDT直接通过,而不是通过ATAGs通过
由于在0x5000_0000加载虚拟机监控程序时,内核不会试图覆盖它,因此我假设在解析FDT/命令行之前,Linux不会触及某些内存区域。我需要知道这是不是真的,如果是真的,关于这些记忆区域的一些细节

谢谢

相关问题:

是否有人知道以下两者之间的优先级:ATAGs/kernel命令行/FDT?例如,如果我通过内核命令行保留内存,但不在FDT(.dtb)中,那么它应该工作还是由FDT覆盖命令行?这三者之间是否存在某种连接 ,安全位置从RAM的开始处开始128MB(假设内核加载在该区域,这应该是)。如果zImage在内存中的加载低于解压缩映像的结束地址,则它可能会在开始解压缩之前将自身重新定位到更高的位置。但除此之外,内核在内存中解压映像的末尾之外还有一个.bss区域

(请注意,您的FDT和initrd位置已经违反了本规范,并且您要保留的内存块包括这两个位置。)


实际上,您的保留区域应该位于内存中的FDT和initrd之后,即0x50000000。但是任何从RAM开始>0x08000000的东西都应该可以移植,只要它不会覆盖内存中的FDT、initrd或U-Boot。

内核/FDT/bootloader命令行的优先级取决于内核配置-进行菜单配置并在“引导选项”下进行检查。您可以将ATAGS与内置命令行组合,但不能使用FDT-毕竟,所选的FDT
节点应该由引导加载程序生成-U-boot的FDT支持是可以的,因此如果您需要FDT命令行,您应该让它这样做,而不是将其烘焙到.dts中


内核在获得内存映射之前是相当保守的,因为它必须盲目地相信引导加载程序已经按照指定的方式进行了部署。另一方面,U-boot正在到处复制它自己的一些部分,并且肯定是RAM高端的罪魁祸首——如果你在(我认为)
common/board\U f.c
中定义DEBUG
,你会得到它在重新定位过程中遇到的问题的转储(不包括Exynos iRAM SPL/boot代码,但这在这里无论如何都不会有什么不同).

如果U-Boot可以覆盖您的虚拟机监控程序代码,那么您还没有完全覆盖。您应该首先关注这一点:来宾运行时不可能更改虚拟机监控程序。重新考虑内存隔离的设计。我没有说U-Boot是覆盖我的虚拟机监控程序的:它是Linux内核。我的虚拟机监控程序代码在u-boot(虚拟机监控程序由u-boot加载)和内核(虚拟机监控程序加载linux)之间执行。并不是它实际上覆盖了它,只是它试图(显然导致了一个炒作陷阱)纠正我的误解,所以看起来记忆隔离是可以的。但是,您没有配置来宾地址空间以便0x40000000映射到0x0c800000吗?我为什么要这样做?这将导致提供给Linux的整个FDT信息严重不一致。0x0C800000=200MB(十六进制),不是地址:)该死!我不知道