Re: Announcement of aborting HAXM maintenance

[Peter Maydell]

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