On 4/24/21 7:28 AM, Markus Armbruster wrote:
> Philippe Mathieu-Daudé <f4...@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) }
Cc'ing APIC maintainers because I'm lost.
