On Fri, 22 Mar 2024 at 14:08, Cédric Le Goater <clego...@redhat.com> wrote: > > On 3/20/24 16:00, Peter Maydell wrote: > > On Wed, 20 Mar 2024 at 14:10, Mark Burton <mbur...@qti.qualcomm.com> wrote: > >> I’d broaden this to all ’signals’ (IRQ, Reset etc) - and I guess > >> similar statements apply, with the “bridge” between the function > >> and the GPIO mechanism moved closer or further from the originator(s) > >> of the activity. > >> > >> The issue isn’t my “machine” model, rather the compose-ability of > >> (any) such machine. A-priori, a model writer doesn’t know if they > >> should respond directly to an NMI or not - Hence they dont know if > >> they should implement the TYPE_NMI or not. That’s a decision only > >> the machine composer knows. > >> My suggestion would be to use a GPIO interface to models, which can > >> then be appropriately wired. (And, hence, to have a single place > >> that implements the TYPE_NMI interface and provides the GPIO wire > >> ready for wiring to appropriate devices). > > > > I feel like that's a long way in the future, but my back-of-the-envelope > > design sketch of that is that the TYPE_MACHINE class that's implementing > > the "I am just a container for all the devices that the user has > > specified and wired together" machine would itself implement TYPE_NMI and > > when an NMI came in it would assert a GPIO line that the user could > > wire up, or not wire up, as they chose. > > > > Right now we can't do that though, because, among other reasons, > > TYPE_MACHINE isn't a TYPE_DEVICE. (I do want to fix that, though: > > I'm hoping it won't be too difficult.) > > Oh that's interesting. Will that introduce an extra level of container > with multiple machines below ?
No, I don't intend that we should have multiple machines in one simulation, only that the thing which is "container for all the machine's devices" shouldn't be a weirdly distinct type from the SoC "container for devices" devices. What I'm primarily hoping to remedy by making TYPE_MACHINE a subclass of TYPE_DEVICE to deal with inconsistencies like: * reset of machine objects is nonstandard * machine models can't use facilities like having qdev gpio lines, so wind up calling qemu_allocate_irqs() directly None of these are big things, but they're a bit paper-cut-ish. -- PMM