Andreas Färber <afaer...@suse.de> writes: > Am 01.08.2012 22:02, schrieb Anthony Liguori: >> Devices do one of two things today: >> >> 1) register a reset callback >> >> 2) implement a reset method that is invoked through it's parent bus >> >> Since I don't expect CPUs to exist on a bus, it's not immediately clear >> to me that (1) isn't going to be what we do for quite some time. > > Err, I thought devices implement a function assigned to a > DeviceClass::reset, no? That would be (2) on your list and we've been > working on ripping out (1) for devices, on sPAPR for instance. > (2) is what we already have with CPUClass::reset.
Something has to call DeviceClass::reset. That's done through a BusState. Whenever a bus is created, a qemu_register_reset() call is made to invoke the reset method on any device that's part of the bus. So just implementing DeviceClass::reset doesn't automatically mean the reset function will be called. In the short term, I think we'll need to still register a reset handler. > The only remaining issue is that the CPUClass::reset callback is not > automatically called on machine/bus reset yet. > > And what I was saying is that moving the code is NOT an improvement. It > is NO functional change and it is NOT a prerequisite for any change on > the list today. So it is not needed for the to be released 1.2. > > A very low hanging fruit for 1.2 would be to register a SINGLE central > reset callback that iterates through the globally available CPU list and > calls ->reset on each! Then we can drop the reset callbacks in most > machines rather than moving old code around. Relying on the CPU list for this isn't very QOM-like. A better approach would be to make all CPUs appear in a container and then have the reset propagate through container. Reset is a complicated beast. While we model a single reset line today, this isn't technically correct. I believe the distinction between reset types start to matter with PCI-e actually. I do think any reduction in what's happening in machine is a net win. Even if we refactor this later, having the machine code do less and devices do more is an improvement. Regards, Anthony Liguori > > Regards, > Andreas > >> >> Regards, >> >> Anthony Liguori >> >>> >>> Regards, >>> Andreas >>> >>> -- >>> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany >>> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg >> > > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
