On Tue, Feb 16, 2016 at 02:36:49PM +0200, Marcel Apfelbaum wrote: > >>2. PCI devices with no driver installed are not re-mapped. This can be OK > >> from the Windows point of view because Resources Window does not show > >> the MMIO range > >> for this device. > >> > >> If the other (re-mapped) device is working, is pure luck. Both Memory > >> Regions occupy the same range > >> and have the same priority. > >> > >>We need to think about how to solve this. > >>One way would be to defer the BAR activation to the guest OS, but I am not > >>sure of the consequences. > >deferring won't solve problem as rebalancing could happen later > >and make BARs overlap. > > Why not? If we do not activate the BAR in firmware and Windows does not have > a driver > for it, will not activate it at all, right? > Why would Windows activate the device BAR if it can't use it? At least this > is what I hope. > Any other idea would be appreciated. >
I wonder whether this is related to setting PnP in CMOS. See e.g. http://oss.sgi.com/LDP/HOWTO/Plug-and-Play-HOWTO-4.html and https://support.microsoft.com/en-us/kb/321779 > >I've noticed that at startup Windows unmaps and then maps BARs > >at the same addresses where BIOS've put them before. > > Including devices without a working driver? > > > Thanks, > Marcel > > > > >>And this does not solve the ivshmem problem. > >So far the only way to avoid overlapping BARs due to Windows > >doing rebalancing for driver-less devices is to pin such > >BARs statically with _CRS in ACPI table but as Michael said > >it fragments PCI address-space. > > > >> > >>Thanks, > >>Marcel > >> > >> > >> > >> > >> > >
