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

[Michael S. Tsirkin]

On Mon, Apr 09, 2012 at 11:07:03AM +0300, Gleb Natapov wrote:
> On Sun, Apr 08, 2012 at 10:48:02PM +0300, Michael S. Tsirkin wrote:
> > On Sun, Apr 08, 2012 at 03:45:38PM -0300, Marcelo Tosatti wrote:
> > > On Sun, Apr 08, 2012 at 10:15:26AM +0300, Michael S. Tsirkin wrote:
> > > > On Sun, Apr 08, 2012 at 02:13:00AM -0300, Marcelo Tosatti wrote:
> > > > > On Wed, Apr 04, 2012 at 11:51:00PM -0600, Alex Williamson wrote:
> > > > > > We've been batting this one back and forth.  This series includes
> > > > > > several of the cleanups and specification clarifications from my
> > > > > > series awhile back.  Patch 5 is my proposed alternative to
> > > > > > Michael's PCI hotplug race fix.  Since that version I added slot
> > > > > > present tracking so we can be a little more strategic about which
> > > > > > slots we ask the guest to check.  The approach for that path is
> > > > > > described in the commit log.  I tested hotplug on both Linux an
> > > > > > Windows guests (XP + 2k8), intentionally trying to do back to back
> > > > > > device_add and device_del to get a race, but couldn't (I did
> > > > > > however get a glibc double free that seems unrelated to this
> > > > > > series).
> > > > > > 
> > > > > > Long term I'd like to deprecate the up/down PCI hotplug interface
> > > > > > and move to a new model.  I think perhaps we should define 3 new
> > > > > > registers:
> > > > > > 
> > > > > > 1) Device present in slot bitmap (foundation already in 5/5 here)
> > > > > > 2) Virtual slot power state bitmap
> > > > > > 3) Requested slot date bitmap
> > > > > > 
> > > > > > With these we should be able to do proper _STA, _PS0, and _PS3.
> > > > > > We'd maintain the eject register for _EJ0, but deprecate up/down.
> > > > > 
> > > > > What problem are you trying to address by doing so?
> > > > > 
> > > > > 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?
> > > 
> > > Can't these use native PCI PM?
> > 
> > I haven't looked at PM closely but I think to support D3-cold
> > you remove power from the host component. I think this means that
> > we need host PCI bridge support.
> > 
> And since host PCI bridge we emulate does not have it, we invent our own
> mechanism. When we will move to a chipset that supports PM we will do it
> according to its spec.

Yes.
Playing devil's advocate here, for PM we probably need PME#
support and that probably means another register.

> --
>                       Gleb.