On Thu, 19 Jan 2023 at 10:34, Stefan Weil via <qemu-devel@nongnu.org> wrote: > > Am 19.01.23 um 11:12 schrieb Daniel P. Berrangé: > > On Thu, Jan 19, 2023 at 03:56:04AM +0000, Wang, Wenchao wrote: > >> Hi, Philippe, > >> > >> Intel decided to abort the development of HAXM and the maintenance > >> of its QEMU part. Should we submit a patch to mark the Guest CPU > >> Cores (HAXM) status as Orphan and remove the maintainers from the > >> corresponding list? Meanwhile, should the code enabling HAX in QEMU > >> once committed by the community be retained? > > > > If you no longer intend to work on QEMU bits related to HAXM, then > > yes, you should send a patch for the MAINTAINERS file to remove you > > name and mark it as "Orphan" status. > > > > We would not normally delete code from QEMU, merely because it has > > been orphaned. If it is still known to work then we would retain > > it indefinitely, unless some compelling reason arises to drop it. > > This gives time for any potential users to adjust their plans, > > and/or opportunity for other interested people to take over the > > maintenance role. > > HAXM will not only be no longer maintained in QEMU, but also the > necessary framework for macOS and Windows will be retired. See > https://github.com/intel/haxm#status on their GitHub page. As stated > there, macOS provides HVF which can be used instead of HAXM, and Windows > users can use WHPX. Both HVF and WHPX are supported by QEMU. As far as I > know HAXM could only provide a limited RAM size (2 GiB?). Maybe it still > has more deficits. And unmaintained HAXM drivers for macOS and Windows > might be a security risk, too. It is also not clear whether the last > downloads of those drivers will be available in the future. > > Therefore I'd prefer to remove the whole HAXM code in QEMU soon, even in > a minor update for this special case.
This sounds like an argument for putting it through our usual deprecate-and-drop lifecycle. thanks -- PMM