From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59244) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjpR4-0004fd-DV for qemu-devel@nongnu.org; Sun, 19 Apr 2015 09:38:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YjpQz-0005Ug-L7 for qemu-devel@nongnu.org; Sun, 19 Apr 2015 09:38:58 -0400 Received: from mx4-phx2.redhat.com ([209.132.183.25]:37891) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjpQz-0005U1-EP for qemu-devel@nongnu.org; Sun, 19 Apr 2015 09:38:53 -0400 Date: Sun, 19 Apr 2015 09:38:48 -0400 (EDT) From: Yan Vugenfirer Message-ID: <1317746293.2713693.1429450728981.JavaMail.zimbra@redhat.com> In-Reply-To: <20150419093928-mutt-send-email-mst@redhat.com> References: <1425399495-13664-1-git-send-email-imammedo@redhat.com> <20150415122851-mutt-send-email-mst@redhat.com> <20150415155909.5eb62abc@nial.brq.redhat.com> <20150419093928-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: "Michael S. Tsirkin" Cc: ghammer@redhat.com, Igor Mammedov , qemu-devel@nongnu.org ----- Original Message ----- > From: "Michael S. Tsirkin" > To: "Igor Mammedov" > Cc: ghammer@redhat.com, "Yan Vugenfirer" , qemu-devel@nongnu.org > Sent: Sunday, April 19, 2015 10:52:37 AM > Subject: Re: [Qemu-devel] [PATCH V14 0/3] Virtual Machine Generation ID > > On Wed, Apr 15, 2015 at 03:59:09PM +0200, Igor Mammedov wrote: > > On Wed, 15 Apr 2015 12:38:57 +0200 > > "Michael S. Tsirkin" wrote: > > > > > 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? > > > Yes. It is part of HCK test kit: https://msdn.microsoft.com/en-us/library/windows/hardware/jj673015(v=vs.85).aspx#About_rebalance_tests > > > 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. > > It seems that WS2012R2 doesn't honor this part of spec, > > it still tries to find matching driver and load it. > > Interesting. Looking at msdn: > https://msdn.microsoft.com/en-us/library/windows/hardware/ff563877(v=vs.85).aspx > Looks like what windows does to rebalance is query device for > rebalancing support, stop driver, rebalance, and restart driver. > > If device has no driver, it seems likely windows will assume > it's safe to rebalance the resources. > > There's also a very old document: > http://www.microsoft.com/whdc/connect/pci/PCI-rsc.mspx > which says it's possible to implement _DSM method to deny rebalance > requests. > Alternatively, we could put this device behind a pci extender, e.g. as > implemented by Marcel. The resources would then be limited by the _CRS > or the root. > > > > > > > This might also avoid driver prompt from windows? > > it isn't. > >