Peter Maydell <peter.mayd...@linaro.org> writes: > On 7 January 2013 20:20, Anthony Liguori <aligu...@us.ibm.com> wrote: >> Peter Maydell <peter.mayd...@linaro.org> writes: >>> On 7 January 2013 19:10, Anthony Liguori <aligu...@us.ibm.com> wrote: >>>> I think reset really ought to just be a bus level concept with >>>> individual implementations for each bus. >>> >>> I'm not sure I really agree here, especially since QOM/qdev are >>> moving away from the idea that there is a single bus tree and every >>> device is on a single bus. >> >> I don't mean a BusState level concept, I mean a PCIBus concept. >> >> There is clearly such a thing as a PCI bus reset. In fact, there are >> multiple types of PCI bus resets. There should be a PCIBus method that >> calls out to PCIDevices on the bus. >> >> But that isn't something that should be fitted into generalized to a >> BusState::reset method. > > Ah, I see what you mean now -- yes, definitely. > >>> If we want to model reset properly we should model actual reset >>> lines (and/or power-cycling). If we don't care we can continue with >>> whatever fudge we like :-) >> >> Yes, and that's basically what qemu_system_reset() is. Of course, we >> model it like everything is directly connected to a single power source >> which is true 99% of the time. That's why we've gotten away with it for >> so long. > > I think the bit that's most creaky here is what you do about devices > that want to assert outgoing irq/whatever lines immediately on > powerup.
This isn't so much a reset problem as a consequence of stateless IRQ lines. If IRQ lines were stateful, this problem wouldn't exist. And yes, I will post Pins one day... Regards, Anthony Liguori > > -- PMM
