> On 29. Oct 2026, at 18:13, Peter Maydell <[email protected]> wrote:
>
> On Thu, 29 Oct 2026 at 17:02, Mohamed Mediouni <[email protected]>
> wrote:
>>
>>
>>
>>> On 29. Oct 2026, at 15:27, Peter Maydell <[email protected]> wrote:
>>>
>>> On Tue, 27 Oct 2026 at 12:03, Mohamed Mediouni <[email protected]>
>>> wrote:
>>>>
>>>> v2:
>>>> - remove GIC_ISPENDR workaround: currently under further investigation
>>>> - simplify SME save/restore patch
>>>> - rework the CPU reset strategy, with also taking care of the GIC CPU
>>>> interface registers.
>>>>
>>>> v1:
>>>>
>>>> - workaround for presumed Hypervisor.framework issue
>>>> - save/restore SME state only when SME is on for the CPU
>>>> - add ID_AA64PFR0_EL1.GIC sync to advertise the system register interface
>>>
>>> I've applied patches 1-4 to target-arm.next; 5 and 6 I left comments on.
>>>
>>> What's the status with the apple-gfx compile failures on macos 27?
>>> (issue #4486)
>>
>> Hi,
>>
>> I think we should just disable building apple-gfx by default for now.
>>
>> It’s private API as of macOS 27, and as long as a decision on whether
>> to keep that reverse-engineered device model isn’t made yet...
>
> That makes sense to me; we've had the vmapple machine disabled by default
> for a long time, and that I'm guessing that was the biggest reason to use
> apple-gfx.
>
> Do you think we should deprecate the "vmapple" machine type, or do
> you hope to resurrect it still?
Hi,
I do hope to get it resurrected as an optional feature still, but
the issue is that it’ll stay (by design) a reverse-engineered model.
I need to spin a new revision of the patches for that though.
It will break from time to time and cannot come with an expectation
of short-term (as in, anything past 6 months) stability/build-ability.
>
> thanks
> -- PMM
