Matthew Wilcox wrote:
quoted text
> 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.)
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html