On Wed, 28 Aug 2024 at 12:16, Danny Canter <danny_can...@apple.com> wrote: > > This patch's main focus is to use the previously added > hvf_get_physical_address_range to inform VM creation > about the IPA size we need for the VM, so we can extend > the default 36b IPA size and support VMs with 64+GB of > RAM. This is done by freezing the memory map, computing > the highest GPA and then (depending on if the platform > supports an IPA size that large) telling the kernel to > use a size >= for the VM. In pursuit of this a couple of > things related to how we handle the physical address range > we expose to guests were altered, but for an explanation of > what we were doing: > > Today, to get the IPA size we were reading id_aa64mmfr0_el1's > PARange field from a newly made vcpu. Unfortunately, HVF just > returns the hosts PARange directly for the initial value and > not the IPA size that will actually back the VM, so we believe > we have much more address space than we actually do today it seems. > > Starting in macOS 13.0 some APIs were introduced to be able to > query the maximum IPA size the kernel supports, and to set the IPA > size for a given VM. However, this still has a couple of issues > on < macOS 15. Up until macOS 15 (and if the hardware supported > it) the max IPA size was 39 bits which is not a valid PARange > value, so we can't clamp down what we advertise in the vcpu's > id_aa64mmfr0_el1 to our IPA size. Starting in macOS 15 however, > the maximum IPA size is 40 bits (if it's supported in the hardware > as well) which is also a valid PARange value so we can set our IPA > size to the maximum as well as clamp down the PARange we advertise > to the guest. This allows VMs with 64+ GB of RAM and should fix the > oddness of the PARange situation as well. > > Signed-off-by: Danny Canter <danny_can...@apple.com>
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org> thanks -- PMM
