Re: Resetting non-qdev children in a 3-phase reset device

[Philippe Mathieu-Daudé]

On 4/24/21 3:04 PM, Philippe Mathieu-Daudé wrote:
> On 4/24/21 7:28 AM, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé <f4bug@amsat.org> writes:
>>>
>>>> Looking at qemu_register_reset() uses I found this commit:
>>>>
>>>> commit 0c7322cfd3fd382c0096c2a9f00775818a878e13
>>>> Date:   Mon Jun 29 08:21:10 2015 +0200
>>>>
>>>>  watchdog/diag288: correctly register for system reset requests
>>>>
>>>>  The diag288 watchdog is no sysbus device, therefore it doesn't get
>>>>  triggered on resets automatically using dc->reset.
>>>>
>>>>  Let's register the reset handler manually, so we get correctly notified
>>>>  again when a system reset was requested. Also reset the watchdog on
>>>>  subsystem resets that don't trigger a full system reset.
>>>>
>>>> Why is the reset() handler in DeviceClass and not in SysbusDeviceClass
>>>> if "Only sysbus devices get reset"? ...
>>>
>>> Ah, probably because the problem is generic to all busses (ISA, ...)
>>> and not just sysbus.
>>
>> diag288 is a bus-less device.  Propagating reset from the root of the
>> qtree to the leaves won't reach it, because the qtree contains only the
>> devices that plug into a qbus.
> 
> I now understand better the diag288 case, but I still don't understand
> the TYPE_APIC one. It has no DeviceClass::reset(), its abstract parent
> TYPE_APIC_COMMON register apic_reset_common() but being TYPE_DEVICE it
> is not on a qbus. It is somehow connected to the X86CPU object, but the
> single call to apic_init_reset() is from do_cpu_init() - not a reset
> method -.
> Is apic_reset_common() dead code? I don't think so because git-blame
> report activity:
> 
>   2013-11-05 266) static void apic_reset_common(DeviceState *dev)
>   2011-10-16 267) {
>   2013-11-05 268)     APICCommonState *s = APIC_COMMON(dev);
>   2012-02-17 269)     APICCommonClass *info = APIC_COMMON_GET_CLASS(s);
>   2015-04-07 270)     uint32_t bsp;
>   2011-10-16 271)
>   2015-04-07 272)     bsp = s->apicbase & MSR_IA32_APICBASE_BSP;
>   2015-04-07 273)     s->apicbase = APIC_DEFAULT_ADDRESS | bsp |
> MSR_IA32_APICBASE_ENABLE;
>   2016-10-19 274)     s->id = s->initial_apic_id;
>   2011-10-16 275)
>   2017-01-31 276)     apic_reset_irq_delivered();
>   2017-01-31 277)
>   2012-02-17 278)     s->vapic_paddr = 0;
>   2012-02-17 279)     info->vapic_base_update(s);
>   2012-02-17 280)
>   2013-11-05 281)     apic_init_reset(dev);
>   2011-10-16 282) }

Similarly the KVM counterpart:

  2014-12-10 220) static void kvm_apic_reset(APICCommonState *s)
  2011-10-16 221) {
  2014-08-28 222)     /* Not used by KVM, which uses the CPU mp_state
instead.  */
  2014-08-28 223)     s->wait_for_sipi = 0;
  2016-09-12 224)
  2016-10-31 225)     run_on_cpu(CPU(s->cpu), kvm_apic_put,
RUN_ON_CPU_HOST_PTR(s));
  2014-12-10 226) }

> 
> Cc'ing APIC maintainers because I'm lost.
>