From: "Michael S. Tsirkin" <mst@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: ghammer@redhat.com, Yan Vugenfirer <yvugenfi@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH V14 0/3] Virtual Machine Generation ID
Date: Sun, 19 Apr 2015 09:52:37 +0200 [thread overview]
Message-ID: <20150419093928-mutt-send-email-mst@redhat.com> (raw)
In-Reply-To: <20150415155909.5eb62abc@nial.brq.redhat.com>
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" <mst@redhat.com> 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?
> >
> > 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.
next prev parent reply other threads:[~2015-04-19 7:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-03 16:18 [Qemu-devel] [PATCH V14 0/3] Virtual Machine Generation ID Igor Mammedov
2015-03-03 16:18 ` [Qemu-devel] [PATCH V14 1/3] docs: vm generation id device's description Igor Mammedov
2015-03-04 19:57 ` Eric Blake
2015-03-03 16:18 ` [Qemu-devel] [PATCH V14 2/3] pc: add a Virtual Machine Generation ID device Igor Mammedov
2015-03-03 17:35 ` Michael S. Tsirkin
2015-03-03 20:33 ` Igor Mammedov
2015-03-04 12:11 ` Michael S. Tsirkin
2015-03-04 13:12 ` Igor Mammedov
2015-03-04 13:49 ` Michael S. Tsirkin
2015-03-04 14:03 ` Andreas Färber
2015-03-04 15:14 ` Igor Mammedov
2015-03-04 15:31 ` Michael S. Tsirkin
2015-03-04 16:33 ` Igor Mammedov
2015-03-04 19:12 ` Michael S. Tsirkin
2015-03-05 14:22 ` Igor Mammedov
2015-03-11 5:35 ` David Gibson
2015-03-19 9:50 ` Michael S. Tsirkin
2015-03-19 11:31 ` Gal Hammer
2015-03-20 4:58 ` David Gibson
2015-03-03 16:18 ` [Qemu-devel] [PATCH V14 3/3] tests: add a unit test for the vmgenid device Igor Mammedov
2015-04-15 10:38 ` [Qemu-devel] [PATCH V14 0/3] Virtual Machine Generation ID Michael S. Tsirkin
2015-04-15 13:59 ` Igor Mammedov
2015-04-19 7:52 ` Michael S. Tsirkin [this message]
2015-04-19 13:38 ` Yan Vugenfirer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150419093928-mutt-send-email-mst@redhat.com \
--to=mst@redhat.com \
--cc=ghammer@redhat.com \
--cc=imammedo@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yvugenfi@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).