public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Zhao, Yu" <yu.zhao@intel.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Mark McLoughlin <markmc@redhat.com>, kvm <kvm@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Chris Wright <chrisw@redhat.com>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>
Subject: Re: Re: KVM PCI device assignment issues
Date: Tue, 24 Feb 2009 17:20:10 +0800	[thread overview]
Message-ID: <49A3BBCA.50000@intel.com> (raw)
In-Reply-To: <20090213173628.GC16841@parisc-linux.org>

Matthew Wilcox wrote:
> On Fri, Feb 13, 2009 at 04:32:47PM +0000, Mark McLoughlin wrote:
>>   - Secondary Bus Reset (SBR) allows software to trigger a reset on all
>>     devices (and functions) behind a PCI bridge.
>>
>>   - A PCI Power Management D-state transition (D3hot to D0) can be used
>>     to reset a device (all functions).
> 
> That's not guaranteed according to PCI PM 1.2:
> 
> 5.4.1. Software Accessible D3 (D3hot)
> 
>   When programmed to D0, the function may return to the D0 Initialized
>   or D0 Uninitialized state without PCI RST# being asserted. This option
>   is determined at design time and allows designs the option of either
>   performing an internal reset or not performing an internal reset.

The No_Soft_Reset bit in the PMCSR indicates which option is chosen at 
design time:

Section 3.2.4. says:
Value at Reset: Device specific
Read/Write: Read Only
When set (“1”), this bit indicates that devices transitioning from D3hot 
to D0 because of PowerState commands do not perform an internal reset. 
Configuration Context is preserved. Upon transition from the D3hot to 
the D0 Initialized state, no additional operating system intervention is 
required to preserve Configuration Context beyond writing the PowerState 
bits. When clear (“0”), devices do perform an internal reset upon 
transitioning from D3hot to D0 via software control of the PowerState 
bits. Configuration Context is lost when performing the soft reset. Upon 
  transition from the D3hot to the D0 state, full reinitialization 
sequence is needed to return the device to D0 Initialized. Regardless of 
this bit, devices that transition from D3hot to D0 by a system or bus 
segment reset will return to the device state D0 Uninitialized with only 
PME context preserved if PME is supported and enabled.

So the reset is guaranteed if the bit is 0.

And I checked the devices on my machine, all of them who have PM perform 
internal reset when transiting from D3hot to D0 (GeForce 7300, Myri-10G, 
E1000 82567, ICH10 SATA, EHCI, etc.)

  parent reply	other threads:[~2009-02-24  9:20 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-13 16:32 KVM PCI device assignment issues Mark McLoughlin
2009-02-13 16:56 ` Greg KH
2009-02-13 17:06   ` Mark McLoughlin
2009-02-13 17:36 ` Matthew Wilcox
2009-02-13 18:22   ` Chris Wright
2009-02-13 19:47     ` Chris Wright
2009-02-24  9:20   ` Zhao, Yu [this message]
2009-02-14  2:12 ` [PATCH] pci: add remove_id sysfs entry Chris Wright
2009-02-14  3:33   ` Greg KH
2009-02-24  1:26     ` Chris Wright
2009-02-24  2:17       ` [PATCH 1/2] PCI: add some sysfs ABI docs Chris Wright
2009-02-24  2:18         ` [PATCH 2/2] PCI: add remove_id sysfs entry Chris Wright
2009-02-24  3:47           ` Greg KH
2009-02-24  5:33             ` Chris Wright
2009-02-24  5:43               ` Greg KH
2009-02-24  3:47         ` [PATCH 1/2] PCI: add some sysfs ABI docs Greg KH
2009-02-24  5:08           ` Chris Wright
2009-02-24  5:50       ` [PATCH 1/2 v2] " Chris Wright
2009-02-24  5:52         ` [PATCH 2/2 v2] PCI: add remove_id sysfs entry Chris Wright
2009-02-26  5:37           ` Han, Weidong
2009-02-27  0:27             ` Chris Wright
2009-03-20  0:35           ` Jesse Barnes
2009-02-24 17:37         ` [PATCH 1/2 v2] PCI: add some sysfs ABI docs Jesse Barnes

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=49A3BBCA.50000@intel.com \
    --to=yu.zhao@intel.com \
    --cc=allen.m.kay@intel.com \
    --cc=chrisw@redhat.com \
    --cc=donald.d.dugger@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=markmc@redhat.com \
    --cc=matthew@wil.cx \
    /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