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? thanks -- PMM
