[PATCH] docs/about: Deprecate the 'next-cube' m68k machine

[PATCH] docs/about: Deprecate the 'next-cube' m68k machine

[Thomas Huth]

The machine is incomplete, and unfortunately the hoped-for improvements
never happened. So it's maybe best if we mark this machine as deprecated
and finally remove it again in case it gets into the way of a code
refactoring or other reasons.

Signed-off-by: Thomas Huth <huth@tuxfamily.org>
---
 docs/about/deprecated.rst | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 3b074b9ed4..2f6dadd12f 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -253,6 +253,14 @@ deprecated; use the new name ``dtb-randomness`` instead. The new name
 better reflects the way this property affects all random data within
 the device tree blob, not just the ``kaslr-seed`` node.
 
+``next-cube`` m68k machine (since 8.2)
+''''''''''''''''''''''''''''''''''''''
+
+The machine never got fully implemented and can only show the firmware prompt.
+Given the incomplete state and slow progress on improvements, it might get
+removed again without replacement.
+
+
 Backend options
 ---------------
 
-- 
2.41.0

Re: [PATCH] docs/about: Deprecate the 'next-cube' m68k machine

[Mark Cave-Ayland]

On 07/10/2023 08:23, Thomas Huth wrote:

(added Natalia who was the GSoC mentor for the NeXT cube work)

> The machine is incomplete, and unfortunately the hoped-for improvements
> never happened. So it's maybe best if we mark this machine as deprecated
> and finally remove it again in case it gets into the way of a code
> refactoring or other reasons.
> 
> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
> ---
>   docs/about/deprecated.rst | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 3b074b9ed4..2f6dadd12f 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -253,6 +253,14 @@ deprecated; use the new name ``dtb-randomness`` instead. The new name
>   better reflects the way this property affects all random data within
>   the device tree blob, not just the ``kaslr-seed`` node.
>   
> +``next-cube`` m68k machine (since 8.2)
> +''''''''''''''''''''''''''''''''''''''
> +
> +The machine never got fully implemented and can only show the firmware prompt.
> +Given the incomplete state and slow progress on improvements, it might get
> +removed again without replacement.
> +
> +
>   Backend options
>   ---------------

I'm torn a bit by this one - on the one hand the NeXT code could do with some love, 
but then given that the code already uses qdev/QOM then there isn't really much in 
the way of maintenance burden. The main concern for me at the moment is the use of 
the old-style memory accessors that pre-date the memory API.

With my latest ESP patches I think it shouldn't be too hard to update the NeXT DMA 
controller to get SCSI working, so perhaps we can leave it for now if it doesn't 
cause too many problems?

Natalia, any comments from your side? In particular what sources did you point Bryce 
towards in order to reverse engineer the NeXT hardware?


ATB,

Mark.

Re: [PATCH] docs/about: Deprecate the 'next-cube' m68k machine

[Thomas Huth]

On 09/10/2023 21.39, Mark Cave-Ayland wrote:
> On 07/10/2023 08:23, Thomas Huth wrote:
> 
> (added Natalia who was the GSoC mentor for the NeXT cube work)
> 
>> The machine is incomplete, and unfortunately the hoped-for improvements
>> never happened. So it's maybe best if we mark this machine as deprecated
>> and finally remove it again in case it gets into the way of a code
>> refactoring or other reasons.
>>
>> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
>> ---
>>   docs/about/deprecated.rst | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
>> index 3b074b9ed4..2f6dadd12f 100644
>> --- a/docs/about/deprecated.rst
>> +++ b/docs/about/deprecated.rst
>> @@ -253,6 +253,14 @@ deprecated; use the new name ``dtb-randomness`` 
>> instead. The new name
>>   better reflects the way this property affects all random data within
>>   the device tree blob, not just the ``kaslr-seed`` node.
>> +``next-cube`` m68k machine (since 8.2)
>> +''''''''''''''''''''''''''''''''''''''
>> +
>> +The machine never got fully implemented and can only show the firmware 
>> prompt.
>> +Given the incomplete state and slow progress on improvements, it might get
>> +removed again without replacement.
>> +
>> +
>>   Backend options
>>   ---------------
> 
> I'm torn a bit by this one - on the one hand the NeXT code could do with 
> some love, but then given that the code already uses qdev/QOM then there 
> isn't really much in the way of maintenance burden. The main concern for me 
> at the moment is the use of the old-style memory accessors that pre-date the 
> memory API.
> 
> With my latest ESP patches I think it shouldn't be too hard to update the 
> NeXT DMA controller to get SCSI working, so perhaps we can leave it for now 
> if it doesn't cause too many problems?
Almost three years later, the world changed quite a bit. We're getting 
flooded with AI-generated bug reports now, and of course people are 
discovering problems in this old and neglected code, e.g.:

  https://gitlab.com/qemu-project/qemu/-/work_items/4303
  https://gitlab.com/qemu-project/qemu/-/work_items/4304
  https://gitlab.com/qemu-project/qemu/-/work_items/4305

I think it does not make sense to keep this incomplete and experimental code 
around in (upstream) QEMU anymore. If someone wants to complete it, they can 
do it in their own repo first and resubmit it once it is really working. So 
unless someone comes up with very good reasons to keep it in the main 
repository, I'll include the deprecation patch in my next pull request.

  Thomas

Re: [PATCH] docs/about: Deprecate the 'next-cube' m68k machine

[Natalia Portillo]

Well we have now the previous emulator that fully emulates NeXTStep so
it's not so important we keep it but if it's not so much of a
maintenance burden and the latest ESP patched of Mark can make it work
further I think it's better to keep it.

You know my philosophy is for us to emulate as many machines as we can.

Bryce seemed to have his own sources, I do not have any source for
reverse engineering the NeXT machine certainly. Surely some technical
manuals are floating on the internet.

On Mon, 2023-10-09 at 20:39 +0100, Mark Cave-Ayland wrote:
> On 07/10/2023 08:23, Thomas Huth wrote:
> 
> (added Natalia who was the GSoC mentor for the NeXT cube work)
> 
> > The machine is incomplete, and unfortunately the hoped-for
> > improvements
> > never happened. So it's maybe best if we mark this machine as
> > deprecated
> > and finally remove it again in case it gets into the way of a code
> > refactoring or other reasons.
> > 
> > Signed-off-by: Thomas Huth <huth@tuxfamily.org>
> > ---
> >   docs/about/deprecated.rst | 8 ++++++++
> >   1 file changed, 8 insertions(+)
> > 
> > diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> > index 3b074b9ed4..2f6dadd12f 100644
> > --- a/docs/about/deprecated.rst
> > +++ b/docs/about/deprecated.rst
> > @@ -253,6 +253,14 @@ deprecated; use the new name ``dtb-
> > randomness`` instead. The new name
> >   better reflects the way this property affects all random data
> > within
> >   the device tree blob, not just the ``kaslr-seed`` node.
> >   
> > +``next-cube`` m68k machine (since 8.2)
> > +''''''''''''''''''''''''''''''''''''''
> > +
> > +The machine never got fully implemented and can only show the
> > firmware prompt.
> > +Given the incomplete state and slow progress on improvements, it
> > might get
> > +removed again without replacement.
> > +
> > +
> >   Backend options
> >   ---------------
> 
> I'm torn a bit by this one - on the one hand the NeXT code could do
> with some love, 
> but then given that the code already uses qdev/QOM then there isn't
> really much in 
> the way of maintenance burden. The main concern for me at the moment
> is the use of 
> the old-style memory accessors that pre-date the memory API.
> 
> With my latest ESP patches I think it shouldn't be too hard to update
> the NeXT DMA 
> controller to get SCSI working, so perhaps we can leave it for now if
> it doesn't 
> cause too many problems?
> 
> Natalia, any comments from your side? In particular what sources did
> you point Bryce 
> towards in order to reverse engineer the NeXT hardware?
> 
> 
> ATB,
> 
> Mark.

-- 
Regards,
Natalia Portillo
(fey/feyr)

Re: [PATCH] docs/about: Deprecate the 'next-cube' m68k machine

[Philippe Mathieu-Daudé]

Hi Thomas,

On 27/8/26 14:54, Thomas Huth wrote:
> On 09/10/2023 21.39, Mark Cave-Ayland wrote:
>> On 07/10/2023 08:23, Thomas Huth wrote:
>>
>> (added Natalia who was the GSoC mentor for the NeXT cube work)
>>
>>> The machine is incomplete, and unfortunately the hoped-for improvements
>>> never happened. So it's maybe best if we mark this machine as deprecated
>>> and finally remove it again in case it gets into the way of a code
>>> refactoring or other reasons.
>>>
>>> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
>>> ---
>>>   docs/about/deprecated.rst | 8 ++++++++
>>>   1 file changed, 8 insertions(+)
>>>
>>> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
>>> index 3b074b9ed4..2f6dadd12f 100644
>>> --- a/docs/about/deprecated.rst
>>> +++ b/docs/about/deprecated.rst
>>> @@ -253,6 +253,14 @@ deprecated; use the new name ``dtb-randomness`` 
>>> instead. The new name
>>>   better reflects the way this property affects all random data within
>>>   the device tree blob, not just the ``kaslr-seed`` node.
>>> +``next-cube`` m68k machine (since 8.2)
>>> +''''''''''''''''''''''''''''''''''''''
>>> +
>>> +The machine never got fully implemented and can only show the 
>>> firmware prompt.
>>> +Given the incomplete state and slow progress on improvements, it 
>>> might get
>>> +removed again without replacement.
>>> +
>>> +
>>>   Backend options
>>>   ---------------
>>
>> I'm torn a bit by this one - on the one hand the NeXT code could do 
>> with some love, but then given that the code already uses qdev/QOM 
>> then there isn't really much in the way of maintenance burden. The 
>> main concern for me at the moment is the use of the old-style memory 
>> accessors that pre-date the memory API.
>>
>> With my latest ESP patches I think it shouldn't be too hard to update 
>> the NeXT DMA controller to get SCSI working, so perhaps we can leave 
>> it for now if it doesn't cause too many problems?
> Almost three years later, the world changed quite a bit. We're getting 
> flooded with AI-generated bug reports now, and of course people are 
> discovering problems in this old and neglected code, e.g.:
> 
>   https://gitlab.com/qemu-project/qemu/-/work_items/4303
>   https://gitlab.com/qemu-project/qemu/-/work_items/4304
>   https://gitlab.com/qemu-project/qemu/-/work_items/4305

Hobbyist motivated machine emulations never committed to be
secure. While I appreciate these bug reports for the overall
quality of the project, I'm taking these one as lowest priority.
I wouldn't even mind of closing them as WONTFIX "Thanks ...".

"code should not be reached" is exactly what we expect in these
cases. We deliberately not implemented those code paths because
the guests we use don't access them. If a real guest is accessing
then I'm sure someone will end implementing the missing parts.
Fuzzer-generated guests are not useful at all for the hobbyist
part of the project.

> 
> I think it does not make sense to keep this incomplete and experimental 
> code around in (upstream) QEMU anymore. If someone wants to complete it, 
> they can do it in their own repo first and resubmit it once it is really 
> working. So unless someone comes up with very good reasons to keep it in 
> the main repository, I'll include the deprecation patch in my next pull 
> request.
> 
>   Thomas
> 
> 

Re: [PATCH] docs/about: Deprecate the 'next-cube' m68k machine

[Peter Maydell]

On Thu, 27 Aug 2026 at 17:09, Philippe Mathieu-Daudé
<philmd@oss.qualcomm.com> wrote:
>
> Hi Thomas,
>
> On 27/8/26 14:54, Thomas Huth wrote:
> > On 09/10/2023 21.39, Mark Cave-Ayland wrote:
> >> On 07/10/2023 08:23, Thomas Huth wrote:
> >>
> >> (added Natalia who was the GSoC mentor for the NeXT cube work)
> >>
> >>> The machine is incomplete, and unfortunately the hoped-for improvements
> >>> never happened. So it's maybe best if we mark this machine as deprecated
> >>> and finally remove it again in case it gets into the way of a code
> >>> refactoring or other reasons.

> >> I'm torn a bit by this one - on the one hand the NeXT code could do
> >> with some love, but then given that the code already uses qdev/QOM
> >> then there isn't really much in the way of maintenance burden. The
> >> main concern for me at the moment is the use of the old-style memory
> >> accessors that pre-date the memory API.
> >>
> >> With my latest ESP patches I think it shouldn't be too hard to update
> >> the NeXT DMA controller to get SCSI working, so perhaps we can leave
> >> it for now if it doesn't cause too many problems?

> > Almost three years later, the world changed quite a bit. We're getting
> > flooded with AI-generated bug reports now, and of course people are
> > discovering problems in this old and neglected code, e.g.:
> >
> >   https://gitlab.com/qemu-project/qemu/-/work_items/4303
> >   https://gitlab.com/qemu-project/qemu/-/work_items/4304
> >   https://gitlab.com/qemu-project/qemu/-/work_items/4305
>
> Hobbyist motivated machine emulations never committed to be
> secure. While I appreciate these bug reports for the overall
> quality of the project, I'm taking these one as lowest priority.
> I wouldn't even mind of closing them as WONTFIX "Thanks ...".

I agree, but also they can prompt us to look and say "actually
this machine is no longer used / never got sufficiently
implemented to be useful / has no maintainer" (cf musicpal).
So the questions here are:
 * is the machine's functionality better than it was in 2023:
   can we boot something beyond just the firmware now?
 * is anybody planning to actively work on it?
 * is anybody using it?

-- PMM

Re: [PATCH] docs/about: Deprecate the 'next-cube' m68k machine

[Daniel P. Berrangé]

On Thu, Aug 27, 2026 at 06:32:43PM +0100, Peter Maydell wrote:
> On Thu, 27 Aug 2026 at 17:09, Philippe Mathieu-Daudé
> <philmd@oss.qualcomm.com> wrote:
> >
> > Hi Thomas,
> >
> > On 27/8/26 14:54, Thomas Huth wrote:
> > > On 09/10/2023 21.39, Mark Cave-Ayland wrote:
> > >> On 07/10/2023 08:23, Thomas Huth wrote:
> > >>
> > >> (added Natalia who was the GSoC mentor for the NeXT cube work)
> > >>
> > >>> The machine is incomplete, and unfortunately the hoped-for improvements
> > >>> never happened. So it's maybe best if we mark this machine as deprecated
> > >>> and finally remove it again in case it gets into the way of a code
> > >>> refactoring or other reasons.
> 
> > >> I'm torn a bit by this one - on the one hand the NeXT code could do
> > >> with some love, but then given that the code already uses qdev/QOM
> > >> then there isn't really much in the way of maintenance burden. The
> > >> main concern for me at the moment is the use of the old-style memory
> > >> accessors that pre-date the memory API.
> > >>
> > >> With my latest ESP patches I think it shouldn't be too hard to update
> > >> the NeXT DMA controller to get SCSI working, so perhaps we can leave
> > >> it for now if it doesn't cause too many problems?
> 
> > > Almost three years later, the world changed quite a bit. We're getting
> > > flooded with AI-generated bug reports now, and of course people are
> > > discovering problems in this old and neglected code, e.g.:
> > >
> > >   https://gitlab.com/qemu-project/qemu/-/work_items/4303
> > >   https://gitlab.com/qemu-project/qemu/-/work_items/4304
> > >   https://gitlab.com/qemu-project/qemu/-/work_items/4305
> >
> > Hobbyist motivated machine emulations never committed to be
> > secure. While I appreciate these bug reports for the overall
> > quality of the project, I'm taking these one as lowest priority.
> > I wouldn't even mind of closing them as WONTFIX "Thanks ...".
> 
> I agree, but also they can prompt us to look and say "actually
> this machine is no longer used / never got sufficiently
> implemented to be useful / has no maintainer" (cf musicpal).
> So the questions here are:
>  * is the machine's functionality better than it was in 2023:
>    can we boot something beyond just the firmware now?
>  * is anybody planning to actively work on it?
>  * is anybody using it?

I don't mind about the quality, as we never claim this stuff
is providing a security boundary, but I do wonder whether the
bar for merging a machine should have been higher than
"shows firmware prompt" ?

Are there other machines we have merged with that level of
very limited functionality ? 

Is it reasonable to say "boot a guest OS" is a criteria for
merging machines in future ?

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH] docs/about: Deprecate the 'next-cube' m68k machine

[Peter Maydell]

On Thu, 27 Aug 2026 at 18:45, Daniel P. Berrangé <berrange@redhat.com> wrote:
> I don't mind about the quality, as we never claim this stuff
> is providing a security boundary, but I do wonder whether the
> bar for merging a machine should have been higher than
> "shows firmware prompt" ?
>
> Are there other machines we have merged with that level of
> very limited functionality ?
>
> Is it reasonable to say "boot a guest OS" is a criteria for
> merging machines in future ?

I think the idea behind merging a machine earlier is/was
that it means it doesn't build up as a huge hard to review
patchset waiting until all the functionality is there enough
to boot a full OS. That can be an awkward workflow, especially
with multiple contributors.

But allowing in a half-finished machine only works out when the
contributors working on it are actually here and continuing
to work on it -- the failure mode is a half-finished thing.
That's why "is anybody planning to actively work on it?" was
one of my questions earlier.

-- PMM

Re: [PATCH] docs/about: Deprecate the 'next-cube' m68k machine

[Mark Cave-Ayland]

On 27/08/2026 18:32, Peter Maydell wrote:

> On Thu, 27 Aug 2026 at 17:09, Philippe Mathieu-Daudé
> <philmd@oss.qualcomm.com> wrote:
>>
>> Hi Thomas,
>>
>> On 27/8/26 14:54, Thomas Huth wrote:
>>> On 09/10/2023 21.39, Mark Cave-Ayland wrote:
>>>> On 07/10/2023 08:23, Thomas Huth wrote:
>>>>
>>>> (added Natalia who was the GSoC mentor for the NeXT cube work)
>>>>
>>>>> The machine is incomplete, and unfortunately the hoped-for improvements
>>>>> never happened. So it's maybe best if we mark this machine as deprecated
>>>>> and finally remove it again in case it gets into the way of a code
>>>>> refactoring or other reasons.
> 
>>>> I'm torn a bit by this one - on the one hand the NeXT code could do
>>>> with some love, but then given that the code already uses qdev/QOM
>>>> then there isn't really much in the way of maintenance burden. The
>>>> main concern for me at the moment is the use of the old-style memory
>>>> accessors that pre-date the memory API.
>>>>
>>>> With my latest ESP patches I think it shouldn't be too hard to update
>>>> the NeXT DMA controller to get SCSI working, so perhaps we can leave
>>>> it for now if it doesn't cause too many problems?
> 
>>> Almost three years later, the world changed quite a bit. We're getting
>>> flooded with AI-generated bug reports now, and of course people are
>>> discovering problems in this old and neglected code, e.g.:
>>>
>>>    https://gitlab.com/qemu-project/qemu/-/work_items/4303
>>>    https://gitlab.com/qemu-project/qemu/-/work_items/4304
>>>    https://gitlab.com/qemu-project/qemu/-/work_items/4305
>>
>> Hobbyist motivated machine emulations never committed to be
>> secure. While I appreciate these bug reports for the overall
>> quality of the project, I'm taking these one as lowest priority.
>> I wouldn't even mind of closing them as WONTFIX "Thanks ...".
> 
> I agree, but also they can prompt us to look and say "actually
> this machine is no longer used / never got sufficiently
> implemented to be useful / has no maintainer" (cf musicpal).
> So the questions here are:
>   * is the machine's functionality better than it was in 2023:
>     can we boot something beyond just the firmware now?
>   * is anybody planning to actively work on it?
>   * is anybody using it?

The ESP rewrite solved a number of problems and it is possible to load a kernel from 
a disk image and start executing it. I do have a series that further tidies up the 
machine (with fixes for the DMA controller) but it needs a bit more work to finish: I 
believe that should be able to get a pre-installed disk image to userspace.

The assert()s are really there to catch unhandled accesses during boot and they 
aren't considered a security boundary so I think it's fine to close these as WONTFIX 
with a comment that the device is currently unimplemented and not within our security 
boundary.

Certainly booting NeXTstep was useful in figuring out parts of the ESP rewrite and 
also for helping test the 68040 emulation so it's not completely useless...


ATB,

Mark.

Re: [PATCH] docs/about: Deprecate the 'next-cube' m68k machine

[Mark Cave-Ayland]

On 27/08/2026 18:45, Daniel P. Berrangé wrote:

> On Thu, Aug 27, 2026 at 06:32:43PM +0100, Peter Maydell wrote:
>> On Thu, 27 Aug 2026 at 17:09, Philippe Mathieu-Daudé
>> <philmd@oss.qualcomm.com> wrote:
>>>
>>> Hi Thomas,
>>>
>>> On 27/8/26 14:54, Thomas Huth wrote:
>>>> On 09/10/2023 21.39, Mark Cave-Ayland wrote:
>>>>> On 07/10/2023 08:23, Thomas Huth wrote:
>>>>>
>>>>> (added Natalia who was the GSoC mentor for the NeXT cube work)
>>>>>
>>>>>> The machine is incomplete, and unfortunately the hoped-for improvements
>>>>>> never happened. So it's maybe best if we mark this machine as deprecated
>>>>>> and finally remove it again in case it gets into the way of a code
>>>>>> refactoring or other reasons.
>>
>>>>> I'm torn a bit by this one - on the one hand the NeXT code could do
>>>>> with some love, but then given that the code already uses qdev/QOM
>>>>> then there isn't really much in the way of maintenance burden. The
>>>>> main concern for me at the moment is the use of the old-style memory
>>>>> accessors that pre-date the memory API.
>>>>>
>>>>> With my latest ESP patches I think it shouldn't be too hard to update
>>>>> the NeXT DMA controller to get SCSI working, so perhaps we can leave
>>>>> it for now if it doesn't cause too many problems?
>>
>>>> Almost three years later, the world changed quite a bit. We're getting
>>>> flooded with AI-generated bug reports now, and of course people are
>>>> discovering problems in this old and neglected code, e.g.:
>>>>
>>>>    https://gitlab.com/qemu-project/qemu/-/work_items/4303
>>>>    https://gitlab.com/qemu-project/qemu/-/work_items/4304
>>>>    https://gitlab.com/qemu-project/qemu/-/work_items/4305
>>>
>>> Hobbyist motivated machine emulations never committed to be
>>> secure. While I appreciate these bug reports for the overall
>>> quality of the project, I'm taking these one as lowest priority.
>>> I wouldn't even mind of closing them as WONTFIX "Thanks ...".
>>
>> I agree, but also they can prompt us to look and say "actually
>> this machine is no longer used / never got sufficiently
>> implemented to be useful / has no maintainer" (cf musicpal).
>> So the questions here are:
>>   * is the machine's functionality better than it was in 2023:
>>     can we boot something beyond just the firmware now?
>>   * is anybody planning to actively work on it?
>>   * is anybody using it?
> 
> I don't mind about the quality, as we never claim this stuff
> is providing a security boundary, but I do wonder whether the
> bar for merging a machine should have been higher than
> "shows firmware prompt" ?

That's a tricky one, as Bryce did some really good reverse engineering during GSoC 
but I think if this were the situation today we would likely not merge it without 
discussion around future direction and maintainership.

> Are there other machines we have merged with that level of
> very limited functionality ?
> 
> Is it reasonable to say "boot a guest OS" is a criteria for
> merging machines in future ?


ATB,

Mark.

Re: [PATCH] docs/about: Deprecate the 'next-cube' m68k machine

[Thomas Huth]

On 27/08/2026 19.32, Peter Maydell wrote:
> On Thu, 27 Aug 2026 at 17:09, Philippe Mathieu-Daudé
> <philmd@oss.qualcomm.com> wrote:
>>
>> Hi Thomas,
>>
>> On 27/8/26 14:54, Thomas Huth wrote:
>>> On 09/10/2023 21.39, Mark Cave-Ayland wrote:
>>>> On 07/10/2023 08:23, Thomas Huth wrote:
>>>>
>>>> (added Natalia who was the GSoC mentor for the NeXT cube work)
>>>>
>>>>> The machine is incomplete, and unfortunately the hoped-for improvements
>>>>> never happened. So it's maybe best if we mark this machine as deprecated
>>>>> and finally remove it again in case it gets into the way of a code
>>>>> refactoring or other reasons.
> 
>>>> I'm torn a bit by this one - on the one hand the NeXT code could do
>>>> with some love, but then given that the code already uses qdev/QOM
>>>> then there isn't really much in the way of maintenance burden. The
>>>> main concern for me at the moment is the use of the old-style memory
>>>> accessors that pre-date the memory API.
>>>>
>>>> With my latest ESP patches I think it shouldn't be too hard to update
>>>> the NeXT DMA controller to get SCSI working, so perhaps we can leave
>>>> it for now if it doesn't cause too many problems?
> 
>>> Almost three years later, the world changed quite a bit. We're getting
>>> flooded with AI-generated bug reports now, and of course people are
>>> discovering problems in this old and neglected code, e.g.:
>>>
>>>    https://gitlab.com/qemu-project/qemu/-/work_items/4303
>>>    https://gitlab.com/qemu-project/qemu/-/work_items/4304
>>>    https://gitlab.com/qemu-project/qemu/-/work_items/4305
>>
>> Hobbyist motivated machine emulations never committed to be
>> secure. While I appreciate these bug reports for the overall
>> quality of the project, I'm taking these one as lowest priority.
>> I wouldn't even mind of closing them as WONTFIX "Thanks ...".

The problem is that closing such tickets likely won't prevent other 
LLM-based "security researchers" to open another ticket for the same problem 
again in the future. So as long as we have such spots in the code, we'll get 
spammed with such AI-based tickets (IIRC some of the past AI tickets already 
had 4 or 5 dups from different people). And every time you have to triage 
the ticket, decide whether it's a real issue or not ... it's just very time 
intensive.

> I agree, but also they can prompt us to look and say "actually
> this machine is no longer used / never got sufficiently
> implemented to be useful / has no maintainer" (cf musicpal).
> So the questions here are:
>   * is the machine's functionality better than it was in 2023:
>     can we boot something beyond just the firmware now?

Mark did some work on the SCSI controller, but I think it's still missing 
some proper interrupt or DMA handling somewhere, so the kernel still does 
not boot properly yet.

>   * is anybody planning to actively work on it?

I was originally hoping that the original author would chime in again once 
the basics had been merged, but unfortunately that never happened.

>   * is anybody using it?
Certainly not. Unless that person enjoys looking at the firmware prompt ;-)

  Thomas

Re: [PATCH] docs/about: Deprecate the 'next-cube' m68k machine

[Thomas Huth]

On 27/08/2026 19.45, Daniel P. Berrangé wrote:
> On Thu, Aug 27, 2026 at 06:32:43PM +0100, Peter Maydell wrote:
>> On Thu, 27 Aug 2026 at 17:09, Philippe Mathieu-Daudé
>> <philmd@oss.qualcomm.com> wrote:
>>>
>>> Hi Thomas,
>>>
>>> On 27/8/26 14:54, Thomas Huth wrote:
>>>> On 09/10/2023 21.39, Mark Cave-Ayland wrote:
>>>>> On 07/10/2023 08:23, Thomas Huth wrote:
>>>>>
>>>>> (added Natalia who was the GSoC mentor for the NeXT cube work)
>>>>>
>>>>>> The machine is incomplete, and unfortunately the hoped-for improvements
>>>>>> never happened. So it's maybe best if we mark this machine as deprecated
>>>>>> and finally remove it again in case it gets into the way of a code
>>>>>> refactoring or other reasons.
...
> I don't mind about the quality, as we never claim this stuff
> is providing a security boundary, but I do wonder whether the
> bar for merging a machine should have been higher than
> "shows firmware prompt" ?

I think merging machines that are only partially working is fine as long as 
there is follow-up work that takes the state of the machine further in the 
direction of completion.

The 'next-cube' machine looked promising first, and merging the code was 
good to prevent the state from further bit-rotting, but unfortunately it 
completely lost traction in the course of time (except for some improvements 
in the related SCSI controller, big thanks to Mark for that work!). Anyway, 
in such cases when there is hardly any progress anymore, we should admit 
that the experiment failed and finally remove such machines again.

> Are there other machines we have merged with that level of
> very limited functionality ?

According to 
https://www.mail-archive.com/qemu-devel@nongnu.org/msg605124.html the 
xlnx-zynqmp-pmu machine is in a similar unfinished state since years.

Maybe also check https://wiki.qemu.org/Testing/Machines to see whether there 
are other machines that don't have a test yet ... those are good candidates, 
too.

> Is it reasonable to say "boot a guest OS" is a criteria for
> merging machines in future ?
I'd say no, work in progress code is fine, as long as there is progress. But 
if the progress is gone and the machine never reaches the "boot a guest OS" 
state, we should also be fine with deprecating and removing it again.

  Thomas