Hi, > > Hmm, I'm wondering whenever it would be useful to have ... > > > > ISADeviceClass->build_aml(Aml *scope, ISADevice *dev); > > in relation to iqr, you said earlier that device doesn't know to which irq > it's mapped. > that might be a problem in this case, likewise for (MM)IO
Right, this is a problem for sysbus, isa seems to not have this problem though. > > ... then just walk all isa devices and call the handler > > (if present). Maybe the same for sysbus. > > There was already such idea (Paolo or Michael), i.e. to move AML code > generation related to specific devices inside of device model (not > only ISA or sysbus), so one would just have to enumerate present > devices in generic way and ask them to provide AML descriptors and be > done with building DSDT. > > Not sure if it's doable in generic way though, especially when it comes to > orchestrating _CRS between various devices. I suspect fully generic is tricky, also because you have to get the hierarchy right. For isa I think it is doable without too much trouble because all isa devices are within the same scope. sysbus is more tricky I suspect. > So it might take awhile to come up with approach which would work nice. > > Simplest way to get job done in case of microvm is to make board > fill in assigned resources in some helper data structure and pass that > to acpi code. Well, I'd try to avoid the helper data structure indirection ... > (another approach - arm/virt uses static 'registry' to distribute > address space/irq and then acpi code just fetches values from there if > device is present + a bunch of shared PCI code to make up dynamic PCI > description) I suspect the reason for the registry on arm is that you can generate both acpi and device tree from it. But maybe that makes sense for sysbus devices (fw_cfg + virtio-mmio for microvm). cheers, Gerd
