From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVhGg-00069V-VQ for qemu-devel@nongnu.org; Tue, 16 Feb 2016 10:10:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aVhGc-0001Tv-S0 for qemu-devel@nongnu.org; Tue, 16 Feb 2016 10:10:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVhGc-0001To-MR for qemu-devel@nongnu.org; Tue, 16 Feb 2016 10:10:18 -0500 Date: Tue, 16 Feb 2016 17:10:13 +0200 From: "Michael S. Tsirkin" Message-ID: <20160216170159-mutt-send-email-mst@redhat.com> References: <20160131170118-mutt-send-email-mst@redhat.com> <20160202105953.476a05bd@nial.brq.redhat.com> <20160202123756-mutt-send-email-mst@redhat.com> <20160209114608.4f89b528@nial.brq.redhat.com> <20160209131656-mutt-send-email-mst@redhat.com> <20160211161605.0022ed38@nial.brq.redhat.com> <20160211180836-mutt-send-email-mst@redhat.com> <56C2F46D.4080907@redhat.com> <20160216131737.7df40a1d@nial.brq.redhat.com> <56C317E1.1020602@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56C317E1.1020602@redhat.com> Subject: Re: [Qemu-devel] [PATCH v19 3/9] pc: add a Virtual Machine Generation ID device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcel Apfelbaum Cc: Xiao Guangrong , ehabkost@redhat.com, Marcel Apfelbaum , ghammer@redhat.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, Igor Mammedov , lersek@redhat.com 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 > >> > >> > >> > >> > >> > >