David Gibson <da...@gibson.dropbear.id.au> writes: > On Thu, Aug 02, 2012 at 02:40:19PM -0500, Anthony Liguori wrote: >> The "root" of the composition tree is the machine. The machine in the >> abstract sense, not the QEMUMachine sense. QEMUMachine::init() should >> eventually become trivial--just create a handful of devices that >> represent the core components of the machine with everything else being >> created through composition. > > So what code controls the order in which "the machine in the abstract > sense" initiates the reset at the top-leve?
There ought to be a hierarchy (based on composition) that reset flows through. In the case of the PC, at the top level of the hierarchy are the CPUs and Northbridge (i440fx). They either are going to sit on the same bus or within a container of some kind. Reset flows through the bus/container to the CPUs and the Northbridge. The northbridge then flows reset through the PCI bus and then to the southbridge and all of the devices behind it. >> Open coded logic in QEMUMachine::init is always bad. Handling reset for >> a specific device in QEMUMachine::init is bad. That goes against the >> idea of making QEMUMachine::init trivial. >> >> However, reset does logically start at QEMUMachine. That doesn't mean >> that QEMUMachine should be explicitly resetting devices in a specific >> order. This is why I was quick to comment on David's patch because the >> argument about having a controller that determines reset ordering was >> silly. While this does exist on some architectures, > > Some platforms; architecture does not imply a particular platform - > this is one of the more subtle and pervasive x86-isms around. > >> it's not at all >> typical. > > So? If it sometimes exists, we need to support that model. The > argument that "real" hardware never has reset order dependencies is > simply incorrect. "Support the model" is different from "make it a first class abstraction". -M pseries is not a real machine. The things it has to do--initialize all devices, build a device tree, then initialize the CPU with where the device tree lives, is unique to !not a real machine. This is what I mean by complex reset logic. It's not just a matter of an ordering of some kind, it's reset X, do A, reset Y, do B, reset Z, do C. The "do [ABC]" is the part that we shouldn't be trying to model as a general mechanism. I'm not saying that we shouldn't support being able to do this, but this is an exception, not the way all other platforms should behave. >> Reset should flow with QEMUMachine::reset just playing the >> role of deciding whether it starts propagating from. >> >> The only machines that can have complex reset logic are ones that can >> afford to take an extremely long time to startup--typically doing a >> tremendous amount of self-checks in the process. These are not common >> among the types of machines QEMU simulates. > > "having at least one order dependency in reset" != "complex and slow > reset logic". It's not an issue of dependency. We're trying to move to a model where everything is a device. QEMUMachine essentially goes away because a user can create the machine by just creating individual devices and tying them together. But this will never be possible with -M pseries because of the "do ABC" logic that it requires which doesn't fit within the model of everything is a device. That's okay. We have the same problem with Xen and I anticipate we'll have the same problem with S390. We should support this model, but that doesn't mean we shouldn't work toward moving everything else to "everything is a device". Regards, Anthony Liguori > > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ > _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson
