[PATCH v2 0/3] hvf: arm: Support creating VMs with 64+GB of RAM on macOS 15+

Danny Canter posted 3 patches 2 months, 3 weeks ago
accel/hvf/hvf-accel-ops.c | 16 +++++++---
hw/arm/virt.c             | 42 ++++++++++++++++++++++++-
hw/i386/x86.c             |  2 ++
include/hw/boards.h       |  5 +++
include/sysemu/hvf_int.h  |  1 +
target/arm/hvf/hvf.c      | 66 +++++++++++++++++++++++++++++++++++++++
target/arm/hvf_arm.h      |  3 ++
target/arm/internals.h    | 19 +++++++++++
target/arm/ptw.c          | 15 +++++++++
target/i386/hvf/hvf.c     |  5 +++
10 files changed, 168 insertions(+), 6 deletions(-)
[PATCH v2 0/3] hvf: arm: Support creating VMs with 64+GB of RAM on macOS 15+
Posted by Danny Canter 2 months, 3 weeks ago
This patchsets focus is on lighting up the ability to create VMs with 64+GB
of RAM through using some new APIs introduced in macOS 13. Due to the IPA sizes
supported in macOS, the first version we can properly support this requirement
is macOS 15 as (if the hardware supports it also) the kernel adds support for a
40b IPA size, which is the first supported ARM PARange value after 36b, so we
can advertise this to the guest properly as well in id_aa64mmfr0_el1.

Today if you asked for a > 64GB VM you'd be met with a pretty unwieldy
HV_BAD_ARGUMENT. On machines without 40b IPA support this patchset also
improves this, and the message mirrors the kvm_type error you'd get on ARM:

"qemu-system-aarch64: -accel hvf: Addressing limited to 36 bits, but memory
exceeds it by 18253611008 bytes"

Changes from V1 to V2 (Thanks Peter for review!):

- Added a new function pointer to MachineClass to be able to freeze the memory
map and compute the highest guest physical address. We use this to inform VM
creation on what IPA size we should ask the kernel for. This is very similar to
what ARM's kvm_type() does.

- Fixed redundant loop in `round_down_to_parange_bit_size`

- Move the splitting up of hv_vm_create logic per platform to a separate patch.
This is mostly for readability.

Danny Canter (3):
  hw/boards: Add hvf_get_physical_address_range to MachineClass
  hvf: Split up hv_vm_create logic per arch
  hvf: arm: Allow creating VMs with 64+GB of RAM on macOS 15+

 accel/hvf/hvf-accel-ops.c | 16 +++++++---
 hw/arm/virt.c             | 42 ++++++++++++++++++++++++-
 hw/i386/x86.c             |  2 ++
 include/hw/boards.h       |  5 +++
 include/sysemu/hvf_int.h  |  1 +
 target/arm/hvf/hvf.c      | 66 +++++++++++++++++++++++++++++++++++++++
 target/arm/hvf_arm.h      |  3 ++
 target/arm/internals.h    | 19 +++++++++++
 target/arm/ptw.c          | 15 +++++++++
 target/i386/hvf/hvf.c     |  5 +++
 10 files changed, 168 insertions(+), 6 deletions(-)

-- 
2.39.5 (Apple Git-154)
Re: [PATCH v2 0/3] hvf: arm: Support creating VMs with 64+GB of RAM on macOS 15+
Posted by Peter Maydell 2 months, 2 weeks ago
On Wed, 28 Aug 2024 at 12:16, Danny Canter <danny_canter@apple.com> wrote:
>
> This patchsets focus is on lighting up the ability to create VMs with 64+GB
> of RAM through using some new APIs introduced in macOS 13. Due to the IPA sizes
> supported in macOS, the first version we can properly support this requirement
> is macOS 15 as (if the hardware supports it also) the kernel adds support for a
> 40b IPA size, which is the first supported ARM PARange value after 36b, so we
> can advertise this to the guest properly as well in id_aa64mmfr0_el1.
>
> Today if you asked for a > 64GB VM you'd be met with a pretty unwieldy
> HV_BAD_ARGUMENT. On machines without 40b IPA support this patchset also
> improves this, and the message mirrors the kvm_type error you'd get on ARM:
>
> "qemu-system-aarch64: -accel hvf: Addressing limited to 36 bits, but memory
> exceeds it by 18253611008 bytes"
>
> Changes from V1 to V2 (Thanks Peter for review!):
>
> - Added a new function pointer to MachineClass to be able to freeze the memory
> map and compute the highest guest physical address. We use this to inform VM
> creation on what IPA size we should ask the kernel for. This is very similar to
> what ARM's kvm_type() does.
>
> - Fixed redundant loop in `round_down_to_parange_bit_size`
>
> - Move the splitting up of hv_vm_create logic per platform to a separate patch.
> This is mostly for readability.

I only had one minor comment on patch 1, so I've applied the
series to target-arm.next and made that tweak there.

thanks
-- PMM