On 2011-04-27 17:09, Michael S. Tsirkin wrote: > On Wed, Apr 27, 2011 at 04:39:53PM +0200, Jan Kiszka wrote: >> On 2011-04-27 16:30, Michael S. Tsirkin wrote: >>>>>> --- a/hw/pci.c >>>>>> +++ b/hw/pci.c >>>>>> @@ -34,6 +34,7 @@ >>>>>> #include "device-assignment.h" >>>>>> #include "qemu-objects.h" >>>>>> #include "range.h" >>>>>> +#include "msi.h" >>>>>> >>>>>> //#define DEBUG_PCI >>>>>> #ifdef DEBUG_PCI >>>>>> @@ -342,6 +343,7 @@ static int get_pci_config_device(QEMUFile *f, void *pv, size_t size) >>>>>> memcpy(s->config, config, size); >>>>>> >>>>>> pci_update_mappings(s); >>>>>> + msi_post_load(s); >>>>> >>>>> Pls don't do this: I'm trying to keep just the core in >>>>> pci.c and all capabilities in separate files. >>>>> msix has msix_load, msi will just need one too, >>>>> and let all devices call that. >>>>> >>>> >>>> Preferred alternatives are...? Registering a vmstate for msi? >>>> >>>> Jan >>> >>> Add msi_load and call that from devices that need it. >>> Like msix_load does now. >>> >> >> msix_load/save are refactoring candidates IMHO. MSI-X has a real need >> for storing additional state information, so it should register its own >> subsection. > > That's an implementation detail though, isn't it. > >> I don't want to offload this burden to the devices also for >> MSI. >> From the devices' POV, why shouldn't msi_init suffice? >> >> Jan > > One can also claim this about config writes: > pci_bridge_write_config(d, address, val, len); > pcie_cap_flr_write_config(d, address, val, len); > pcie_cap_slot_write_config(d, address, val, len); > msi_write_config(d, address, val, len); > pcie_aer_write_config(d, address, val, len); > which arguably just duplicates the initialization sequence. > > What I'm trying to do though is to keep it modular and > keep module inter-dependencies to a minimum, > so that pci is the core and msix depends on it > but not the other way around. I still don't see the bigger benefit in saving a single bidirectional dependency at core level vs. saving additional callbacks at each and every MSI user. The latter is also a source for bugs. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
