> On 21. Jul 2025, at 12:19, Peter Maydell <peter.mayd...@linaro.org> wrote:
>
> On Mon, 14 Jul 2025 at 21:04, Philippe Mathieu-Daudé <phi...@linaro.org>
> wrote:
>>
>> On 14/7/25 18:01, Zenghui Yu wrote:
>>> Quoting Peter Maydell:
>>>
>>> " hvf_sysreg_read_cp() and hvf_sysreg_write_cp() do not check the .access
>>> field of the ARMCPRegInfo to ensure that they forbid writes to registers
>>> that are marked with a .access field that says they're read-only (and
>>> ditto reads to write-only registers). "
>>>
>>> Before we add more registers in GIC sysreg handlers, let's get it correct
>>> by adding the .access checks to hvf_sysreg_read_cp() and
>>> hvf_sysreg_write_cp(). With that, a sysreg access with invalid permission
>>> will result in an UNDEFINED exception.
>>>
>>> Suggested-by: Peter Maydell <peter.mayd...@linaro.org>
>>> Signed-off-by: Zenghui Yu <zenghui...@linux.dev>
>>> ---
>>>
>>> I hard-code the @current_el parameter of cp_access_ok() to 1 because
>>>
>>> * we only support EL0 and EL1 in HVF, and
>>
>> This might change with this work:
>> https://lore.kernel.org/qemu-devel/20250620172751.94231-1-phi...@linaro.org/
>> and plan to leverage M3/M4 for EL2 support:
>> https://developer.apple.com/documentation/hypervisor/hv_vm_config_set_el2_enabled(_:_:)
>
> True, but for 10.1 I'm going to take these patches as-is, because
> they do fix a bug, and handling EL2 in hvf with an emulated GIC is
> going to need a more general look at the GIC code anyway.
> (My preference would be to use the GICv3 which hvf provides in
> macos 15 and up when we can in any case.)
Something to note on the vGIC provided by Hypervisor.framework is that it
provides its serialisable internal state as an opaque structure which isn’t
guaranteed to not change in the future (with however guarantees that it’ll be
readable on newer macOS versions than the one it was generated from).
And is of course not a documented one.
> Syncing the whole VM state for any call through to the GIC
> emulation would be quite heavyweight. I'm not sure if we exactly
> thought through that the state would not be synced here, though:
> the GIC emulation was never written to assume that some CPU
> registers might not be in sync...
>
> thanks
> -- PMM
>
