Re: [PATCH 09/24] macio: Fix to realize "mos6522-cuda" and "mos6522-pmu" devices

[Markus Armbruster]

Peter Maydell <address@hidden> writes:

> On Mon, 18 May 2020 at 06:12, Markus Armbruster <address@hidden> wrote:
>>
>> cuda_init() creates a "mos6522-cuda" device, but it's never realized.
>> Affects machines mac99 with via=cuda (default) and g3beige.
>>
>> pmu_init() creates a "mos6522-pmu" device, but it's never realized.
>> Affects machine mac99 with via=pmu and via=pmu-adb,
>>
>> I wonder how this ever worked.  If the "device becomes real only on
>> realize" thing actually works, then we've always been missing these
>> devices, yet nobody noticed.
>
> Same remark as elsewhere: the devices aren't missing, we just
> got lucky that using them in a half-initialized state happens
> to work for these devices. Could you update the commit messages
> when you reroll this series, please?

Of course.  What about something like this:

    In theory, a device becomes real only on realize.  In practice, the
    transition from unreal to real is a fuzzy one.  The work to make a
    device real can be spread between realize methods (fine),
    instance_init methods (wrong), and board code wiring up the device
    (fine as long as it effectively happens on realize).  Depending on
    what exactly is done where, a device can work even when we neglect
    to realize it.  Nevertheless, it's a clear misuse of the interface.
    Even when it works today (more or less by chance), it can break
    tomorrow.

>> Fix by realizing them in cuda_realize() and pmu_realize(),
>> respectively.
>>
>> Fixes: 6dca62a0000f95e0b7020aa00d0ca9b2c421f341
>> Cc: Laurent Vivier <address@hidden>
>> Signed-off-by: Markus Armbruster <address@hidden>
>> ---
>>  hw/misc/macio/cuda.c | 8 +++-----
>>  hw/misc/macio/pmu.c  | 8 +++-----
>>  2 files changed, 6 insertions(+), 10 deletions(-)
>>
>> diff --git a/hw/misc/macio/cuda.c b/hw/misc/macio/cuda.c
>> index e0cc0aac5d..6d4d135f71 100644
>> --- a/hw/misc/macio/cuda.c
>> +++ b/hw/misc/macio/cuda.c
>> @@ -523,15 +523,13 @@ static void cuda_realize(DeviceState *dev, Error 
>> **errp)
>>  {
>>      CUDAState *s = CUDA(dev);
>>      SysBusDevice *sbd;
>> -    MOS6522State *ms;
>> -    DeviceState *d;
>>      struct tm tm;
>>
>> +    qdev_init_nofail(DEVICE(&s->mos6522_cuda));
>
> Since we init the device with sysbus_init_child_obj() and
> we're in a position here to propagate any realize error
> back up to our caller, it would be nicer to do this via
> setting the realize property rather than qdev_init_nofail().

The error handling will be unreachable.

The proper way to say "error not possible" is of course &error_abort,
not qdev_init_nofail()'s &error_fatal.

Many realize methods misuse the Error interface this way.  NULL instead
of &error_abort is also common.  Cleaning this up is yet another big
task.  But that's no excuse for making it bigger now.

Laurent, would you prefer unreachable error handling or &error_abort?

> That's what this patch from March does:
> https://lists.gnu.org/archive/html/qemu-devel/2020-03/msg04260.html
> (we seem to have let that series drop accidentally,
> probably because it was halfway through release and
> because it touches several architectures at once).

Pity.