On 4/24/21 3:04 PM, Philippe Mathieu-Daudé wrote: > 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) }
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. >