From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiKin-00033U-1x for qemu-devel@nongnu.org; Wed, 15 Apr 2015 06:39:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YiKij-00034s-SX for qemu-devel@nongnu.org; Wed, 15 Apr 2015 06:39:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiKij-00034l-MH for qemu-devel@nongnu.org; Wed, 15 Apr 2015 06:39:01 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3FAd03G007588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 15 Apr 2015 06:39:00 -0400 Date: Wed, 15 Apr 2015 12:38:57 +0200 From: "Michael S. Tsirkin" Message-ID: <20150415122851-mutt-send-email-mst@redhat.com> References: <1425399495-13664-1-git-send-email-imammedo@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1425399495-13664-1-git-send-email-imammedo@redhat.com> Subject: Re: [Qemu-devel] [PATCH V14 0/3] Virtual Machine Generation ID List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: ghammer@redhat.com, Yan Vugenfirer , qemu-devel@nongnu.org On Tue, Mar 03, 2015 at 05:18:12PM +0100, Igor Mammedov wrote: > Changes since v13: > * fix comment style to /*... */ in testcase > * make BAR TARGET_PAGE_SIZE as required by spec > * make BAR prefetchable, spec also says that it shouldn't be > marked as non cached > * ACPI part > * merge separate VGID device with PCI device description > * mark device as not shown in UI, > it hides "VM Generation ID" device from device manager > and leaves only "PCI Standard RAM Controller" device there In an offline chat, Yan (Cc) mentioned that with windows guests, PCI rebalancing can move BAR values around. Yan, could you comment on-list please? Is there a way to force this, for testing? ACPI spec mentions this: If a platform uses a PCI BAR Target operation region, an ACPI OS will not load a native device driver for the associated PCI function. For example, if any of the BARs in a PCI function are associated with a PCI BAR Target operation region, then the OS will assume that the PCI function is to be entirely under the control of the ACPI BIOS. No driver will be loaded. Thus, a PCI function can be used as a platform controller for some task (hot-plug PCI, and so on) that the ACPI BIOS performs. This might also avoid driver prompt from windows? -- MST