> From: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> > Sent: Tuesday, April 26, 2022 9:45 AM > > ... > > Sorry I don't quite follow. pci-hyperv allocates MMIO for the bridge > > window in hv_pci_allocate_bridge_windows() and registers the MMIO > > ranges to the core PCI driver via pci_add_resource(), and later the > > core PCI driver probes the bus/device(s), validates the BAR sizes and > > the pre-initialized BAR values, and uses the BAR configuration. IMO > > the whole process doesn't require the bit PCI_COMMAND_MEMORY to be > > pre-set, and there should be no issue to delay setting the bit to a > > PCI device device's .probe() -> pci_enable_device(). > > IIUC you want to bootstrap devices with PCI_COMMAND_MEMORY clear > (otherwise PCI core would toggle it on and off for eg BAR sizing). > > Is that correct ? Yes, that's the exact purpose of this patch. Do you see any potential architectural issue with the patch? >From my reading of the core PCI code, it looks like this should be safe. Jake has some concerns that I don't quite follow. @Jake, could you please explain the concerns with more details? > If I read PCI core correctly PCI_COMMAND_MEMORY is obviously cleared > only if it is set in the first place and that's what your patch is > changing, namely you boostrap your devices with PCI_COMMAND_MEMORY > clear so that PCI core does not touch it. Yes, this is what exactly the patch is doing. Thanks, -- Dexuan