Re: [Qemu-devel] [PATCH 0/5] PCI hotplug fixes/cleanup

[Michael S. Tsirkin]

On Tue, Apr 10, 2012 at 02:03:05PM -0600, Alex Williamson wrote:
> On Tue, 2012-04-10 at 22:36 +0300, Michael S. Tsirkin wrote:
> > On Tue, Apr 10, 2012 at 12:29:09PM -0600, Alex Williamson wrote:
> > > I never really intended the power state bitmap to be for power
> > > management of any sort, I was trying to support this kind of event flow:
> > > 
> > > http://www.microsoft.com/china/whdc/system/pnppwr/hotadd/hotplugpci.mspx#EYH
> > > 
> > > Hot-add:
> > >  - Generate SCI
> > >  - _Lxx/_Exx method determines which slots to Notify
> > >  - _STA method for slots indicates device present
> > >  - _PS0 requests slot turned on
> > >  - _STA method reports device present & enabled
> > > 
> > > Hot-remove:
> > >  - Generate SCI
> > >  - _Lxx/_Exx method determines which slots to Notify
> > >  - _PS3 powers off slot
> > >  - _EJ0 ejects device
> > >  - _STA verifies success
> > > 
> > > _STA is generated using the "present" and "power" registers and _PSx
> > > methods directly manipulate "power".  We could then have some kind of
> > > "info pcislot" command that allows querying slot state.  Maybe there's
> > > even an opportunity for unpowered slot surprise removal.  In effect, the
> > > "power" register tracks the "actual" state vs the "requested" state, but
> > > if it's controlled by _PSx, it seems better to not try to do a
> > > translation.
> > > 
> > > Are there better models or event flows we should be aiming for?  Thanks,
> > > 
> > > Alex
> > 
> > You already said exactly this and both me and Marcelo responded, no?
> 
> Sorry, difficult to try to summarize a reply to a weekend+ of
> conversation, is this better?
> 
> On Sun, 2012-04-08 at 02:13 -0300, Marcelo Tosatti wrote:
> On Wed, Apr 04, 2012 at 11:51:00PM -0600, Alex Williamson wrote:
> > 
> > What problem are you trying to address by doing so?
> 
> I'm trying to come up with a model that provides better event life
> cycle, clear register ownership, and facilitates features like the event
> flow in the msft link above.  We can get away with asking the guest to
> do extra device checks on slots, but it's a workaround for a broken
> model.
> 
> > What is the need for power control? Clearly there is no advantage in    
> > powering down a virtual device.
> 
> In combination with the "present" register it allows emulating more _STA
> states.
> 
> On Sun, 2012-04-08 at 10:15 +0300, Michael S. Tsirkin wrote:
> On Sun, Apr 08, 2012 at 02:13:00AM -0300, Marcelo Tosatti wrote:
> > > What is the need for power control? Clearly there is no advantage in    
> > > powering down a virtual device.
> > 
> > There probably are for an assigned device?
> 
> That was not my intention
> 
> [Skipping the rest since it's all headed in the direction of using the
> power register to do some kind of chipset/device power control]
> 
> If there was some decision or direction provided by the rest of the
> thread, I missed it, please restate.  Thanks,
> 
> Alex

Some points I remember
- power on is better called slot enabled
- guests dont actually call _PSX like you want them to
  (PS3 for sure, in my testing PS0 too), and _EJ0 must
  remove power
- populated slots after reset must be auto-enabled

HTH