> On 5. Aug 2025, at 01:41, Mohamed Mediouni <[email protected]> wrote:
>
>
>
>> On 5. Aug 2025, at 01:13, Richard Henderson <[email protected]>
>> wrote:
>>
>> On 8/5/25 09:03, Philippe Mathieu-Daudé wrote:
>>> On 4/8/25 16:23, Mohamed Mediouni wrote:
>>>> Signed-off-by: Mohamed Mediouni <[email protected]>
>>>> ---
>>>> accel/hvf/hvf-all.c | 7 +++++--
>>>> hw/arm/virt.c | 41 ++++----------------------------------
>>>> include/hw/boards.h | 4 ++--
>>>> include/system/hvf_int.h | 2 ++
>>>> target/arm/hvf-stub.c | 20 -------------------
>>>> target/arm/hvf/hvf.c | 6 +++---
>>>> target/arm/hvf_arm.h | 3 ---
>>>> target/arm/meson.build | 1 -
>>>> target/arm/whpx/whpx-all.c | 5 +++--
>>>> target/i386/hvf/hvf.c | 10 ++++++++++
>>>> 10 files changed, 29 insertions(+), 70 deletions(-)
>>>> delete mode 100644 target/arm/hvf-stub.c
>>>> diff --git a/target/i386/hvf/hvf.c b/target/i386/hvf/hvf.c
>>>> index 818b50419f..fa06e3b815 100644
>>>> --- a/target/i386/hvf/hvf.c
>>>> +++ b/target/i386/hvf/hvf.c
>>>> @@ -225,6 +225,16 @@ int hvf_arch_init(void)
>>>> return 0;
>>>> }
>>>> +uint32_t hvf_arch_get_default_ipa_bit_size(void)
>>>> +{
>>>> + return 48;
>>>> +}
>>>> +
>>>> +uint32_t hvf_arch_get_max_ipa_bit_size(void)
>>>> +{
>>>> + return 48;
>>> These don't make much sense on x86...
>>
>> They don't *not* make sense. x86 does have two-stage translation, though it
>> has both 48-bit and 52-bit translation.
>>
>> While this is only invoked from hw/arm/virt.c at present, I can see that by
>> piping the path through accel/hvf/ means that x86 needs to provide the
>> symbols. Though perhaps they should just be g_assert_not_reached() stubs
>> for now.
> Random note that probably doesn’t change things: every Intel Mac has 48-bit,
> and extended addressing will never happen as macOS 26 is the last x86 macOS
> release.
>
> The other option I think is just #ifdefing out if
> (mc->get_physical_address_range) in hvf_accel_init based on arch…
Think that I’ll just go the g_assert_not_reached route...