Hacker News Digest

Попытка запустить Linux на Mac mini с чипом M4 столкнулась с неожиданными трудностями из-за новой технологии SPTM — механизма защиты, который блокирует прямой доступ к аппаратным ресурсам, использовавшийся в ранних версиях Asahi Linux. В отличие от M1–M3, где можно было анализировать MMIO-трафик macOS, здесь требовалась глубокая модификация гипервизора m1n1, что вышло за рамки возможностей новичка. Однако автору удалось обойти проблему: отключив строгую безопасность загрузки, установив m1n1 через восстановление macOS и получив доступ к последовательному порту, он начал эксперименты с загрузкой ядра.

Первым барьером оказался заблокированный GXF — компонент, отвечающий за безопасность исключений, который на M4 отключён в режиме raw boot. Затем выяснилось, что регистр RVBAR, задающий точку входа для ядра, уже содержит корректное значение — попытки его перезаписать вызывали сбой. После долгого перерыва автор добился первого вывода через debug_putc, внедрив минимальное устройство дерева и включив earlycon. Ключевым прорывом стало обнаружение, что процессоры M4 теряют состояние при выполнении команды WFI (Wait For Interrupt), что приводило к зависанию. Исправление потребовало патча для m1n1 и ядра Linux, отключающего WFI в ранней стадии загрузки — после этого система начала выводить логи, и Linux наконец заработал.

Преимущества Apple‐устройств связаны с вертикальной интеграцией и оптимизацией аппаратного и программного обеспечения, а не только с более мощными характеристиками. Открытое железо вряд ли существенно изменит финансовый масштаб компании из‐за её огромного объёма продаж — даже если все желающие Linux‐пользователи купят самые дорогие Mac, это не окажет заметного влияния на доходы. Дискуссия о целесообразности открытости аппаратной части продолжается: одни считают, что это расширит рынок, другие уверены, что Apple намеренно продаёт только готовый пакет и не получит выгоды от открытости. Поддержка Linux на Mac остаётся сложной из‐за закрытых протоколов, в частности трекпада, хотя качество сенсора и тактильной отдачи остаётся ключевым фактором превосходства. Для запуска Linux рекомендуется поддерживать проекты вроде Asahi Linux и OEM‐производителей, работающих над драйверами и портами. Обратное проектирование чипов M4 и M6 активно использует инструменты искусственного интеллекта, ускоряя анализ и разработку драйверов.

Эмуляция x86-TSO на ARM — одна из самых сложных задач в совместимости архитектур, поскольку x86 требует строгой согласованности памяти (Total Store Ordering), тогда как ARMv8.0 использует слабую модель упорядочивания, позволяющую значительные аппаратные оптимизации. Это означает, что запись в память на x86 мгновенно видима всем ядрам, а загрузка гарантирует видимость всех предшествующих записей — поведение, ожидаемое программистами. На ARM же записи могут задерживаться в кеше и не быть сразу видимыми другим ядрам без явных барьеров, что нарушает семантику x86-кода, особенно в многопоточных приложениях и синхронных структурах данных.

Ключевые проблемы включают необходимость эмуляции атомарных инструкций (например, LOCK CMPXCHG), которые на ARM требуют дорогостоящих барьеров или циклических попыток с использованием LDXR/STXR; обязательную обработку split-lock операций (когда доступ пересекает границу кеш-линии), которые на ARM не поддерживаются аппаратно и требуют дорогостоящих программных обходов; и работу с некешируемой памятью (uncached), где доступы должны строго соблюдать порядок и не могут быть буферизованы — критично для устройств ввода-вывода и видеопамяти. На UMA-системах (например, Tegra, Snapdragon с Adreno 600+) проблема частично решается через принудительное использование кэшированных буферов в видеодрайверах, что исключает доступ к uncached памяти. Пользователи Asahi Linux с аппаратным битом TSO избегают проблемы естественным образом, но добавление дискретного PCIe GPU вновь вводит несовместимость. Несмотря на прогресс вендоров в решении отдельных аспектов, полное устранение накладных расходов остаётся вызовом, и эмуляция x86-TSO продолжает требовать значительных компромиссов между производительностью и корректностью.

Обсуждение дополняет статью, раскрывая практические аспекты эмуляции x86 на ARM: Apple внедрила TSO-режим в чипы, но не устранила все крайние случаи; FEX демонстрирует прогресс в эмуляции на Linux с поддержкой Steam и Crossover. Apple добавила TSO-режим в свои чипы для эмуляции x86 благодаря вертикальной интеграции и контролю над железом, но это не устраняет все крайние случаи. Спор: слабая модель памяти ARM не даёт значительных преимуществ в производительности, тогда как автор Rosetta 2 утверждает, что она улучшает производительность за счёт гибкой оптимизации. FEX — открытый фреймворк для эмуляции x86 на ARM, спонсируемый Valve, используется в Steam Deck и Crossover Beta, демонстрируя значительный прогресс в эмуляции x86 на Linux. Эмуляция одного ядра может обойти проблемы упорядочивания памяти, но с потерей производительности — приемлемо для устаревших рабочих нагрузок, где скорость не критична. При эмуляции x86 на ARM в пользовательском режиме (например, FEX на Linux) накладные расходы TSO на нативный ARM-код незначительны, так как нативного ARM-кода выполняется крайне мало. Разработка TSO-режима в Apple требовала координации множества команд, что стало возможным благодаря стратегическому приоритету продукта на высоком уровне. FEX на macOS позволяет запускать Wine на чипах M-series, но его использование ограничено из-за анти-ИИ политики, требующей форка. Вопрос о компиляции бинарников в байткод вместо эмуляции не решён, поскольку это требует переписывания всего экосистемного стека, а не только эмулятора.

Linux 7.2 принёс значительный прогресс в поддержке Apple Silicon через Asahi Linux, особенно в управлении питанием CPU. Основная проблема — отсутствие EL3 в чипах Apple, что блокирует использование стандарта PSCI для управления состояниями сна ядер. Вместо этого ядро работает в EL2, а m1n1 — кастомный загрузчик — выступает как промежуточное ПО, позволяющее обойти ограничения. Для сохранения энергии используется глубокий WFI, при котором ядро отключает часть компонентов и сохраняет состояние, но это решение не может быть вынесено в основную ветку ядра из-за нарушения архитектурных требований.

На фронтенде достигнут прорыв: AGX (графика) и DCP (дисплей) теперь могут напрямую передавать фреймы без посредников, что критично для производительности и энергоэффективности. Однако KDE’s Kwin пока не поддерживает такой «многопроцессорный» вывод, отключая DMA-BUF, но исправление ожидается в Plasma 6.8. Также обновлены драйверы I2S, SMC и hwmon, исправлены совместимости с macOS 27. Рост команды и новые разработки — включая поддержку M4 и AVD — стали возможны благодаря спонсорам, чья поддержка позволяет преодолевать сложнейшие аппаратные барьеры.

Тред уходит от техотчёта в контекст вокруг Asahi: усталость от macOS, практичность реверс-инжиниринга Apple, споры о шорткатах и сомнения в долгосрочной нужности проекта. Содержательных технических добавлений мало. Asahi как запасной вариант: @stiray, @wishfish, @tiahura и @a96 сходятся на том, что особенности macOS (шорткаты, невозможность починить систему) раздражают и нужна альтернатива. Спор о шорткатах: @strbean считает Cmd-C/V единственным разумным стандартом. @stiray, @brewmarche и @a96 возражают — нестандартные биндинги macOS создают постоянную боль для мульти-OS пользователей. @wishfish предлагает ремап Command на Control в системных настройках — работает без сторонних инструментов вроде Karabiner. Спор о долгосрочной нужности Asahi: @dgunay и @throwa356262 считают, что ресурсы лучше вложить в Strix Halo, NPU и старые Qualcomm SoC. @raybb и @MBCook возражают аргументом об ewaste и уникальности железной проблемы. @maccard ставит под вопрос тезис о том, что Panther Lake сравняется с Apple Silicon — на рынке нет ноутбука с железом, эквивалентным MacBook Pro. @xoa оспаривает тезис о невозможности общего дискового пространства: ZFS-раздел или iSCSI для сетевого Home работают на M4 mini без нативного Linux на железе. По ARM и WFI на Apple Silicon: @ksec удивлён нарушением духа спеки, @j16sdiz уточняет, что поведение допустимо при наличии архитектурной лицензии Apple, а проблемный регистр доступен только из ядра. @ZiiS просит добавлять в прогресс-репорты Asahi строку о масштабе известных открытых багов — DP Alt Mode уже год работает без упоминания. @dreamcompiler выбрал гибридный путь: Linux в VM на Apple Silicon ради времени работы от батареи и общего доступа к данным с macOS. @owaislone и @LoganDark считают главным нерешённым вызовом Asahi power management и время работы от батареи — Linux проигрывает из-за отсутствия проприетарных драйверов. @djxfade возражает: для Apple нет бизнес-смысла делать Linux first-class, потому что продукт — это связка hardware+software. @djfergus добавляет, что усилия Apple по безопасности объясняют нежелание поддерживать альтернативные ОС. @megous предупреждает: VA-API плохо ложится на v4l2-request — VA-API пересчитывает часть данных из битстрима, а v4l2-request ожидает оригинальный распарсенный битстрим; ссылается на свой форк libva-v4l2-request.

Команда Asahi Linux продолжает работу над поддержкой чипов Apple M3, хотя на данный момент базовая функциональность позволяет только загружать систему до мигающего курсора. Разработчики активно портируют загрузчик m1n1 на язык Rust, что повысит безопасность и поддерживаемость критически важного компонента. Параллельно ведется работа над патчами ядра Linux для версий 6.17 и 6.18, где уже добавлены Device Trees для устройств Apple M2 Pro/Max/Ultra.

Успехи также отмечены в игровой сфере — Wine теперь работает вне muvm, а поддержка графики продолжает совершенствоваться. Несмотря на прогресс с M1 и M2, чипы M3, M4 и недавно анонсированный M5 все еще находятся в стадии обратной разработки. Как отмечают разработчики: "Базовая поддержка M3 существует давно, но она ограничивается возможностью загрузки до мигающего курсора, что полезно только для низкоуровневого реверс-инжиниринга".

• Пользователи обсуждают, что владельцы Mac на M1-M4 чипах по-прежнему не могут полноценно использовать Linux на своих машинах, и это вызывает тревогу, особенно учитывая, что Apple не проявляет особого интереса к поддержке Linux на своих устройствах.
• Участники обсуждения отмечают, что даже несмотря на это, сама по себе поддержка Asahi Linux остается важной, так как она позволяет продлить жизнь этих устройств, когда Apple прекратит поддержку macOS.
• Некоторые участники подчеркивают, что ситуация с Linux на Apple Silicon выглядит как бесконечная борьба, и что это может быть неразрешимой проблемой, если Apple не изменит свою политику.
• Также обсуждается, что в то время как Apple продолжает выпускать новые чипы, Asahi Linux может не успевать за ними, что делает невозможным поддерживать актуальные версии ядра и драйверов.
• Наконец, участники обсуждения отмечают, что существует альтернатива в виде ноутбуков от других производителей, которые лучше подходят для Linux, но они не такие же качественные, как MacBook, что делает выбор сложным для тех, кто предпочитает Linux, но привык к премиальному качеству MacBook.