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.
So I would have organized it differently, with a bugfix first and the rework on top (e.g. make life easier if we want to cherry-pick this change to the stable branch) and there's a bit of discussion about documentation but I'm prepared to apply this as is too if you prefer. For the series: Acked-by: Michael S. Tsirkin <m...@redhat.com> > 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). Reproducible? > 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. > > For a device_add, the 'present' & 'request' bitmaps gets set for > the slot by qemu, gpe.sts set and SCI interrupt sent. The OSPM > can simply compare requested state vs power state and send the > appropriate notify. Same general idea for removal. _STA can be > formed by looking at the 'present' and 'power' bitmaps, and > _PS0/3 perform writes to the power register to indicate the virtual > state. I think this provides a better register ownership model > (qemu owns present/request, OSPM owns power) and also allows us > to differentiate between a guest initiated remove and a platform > (vm manager) initiated remove so we can avoid changing the vm > state in the former case. I'll try to send a patch for this out > soon, but let me know if there are any concerns or suggestions for > a redesign. Thanks, > > Alex > > --- > > Alex Williamson (5): > acpi_piix4: Fix PCI hotplug race > acpi_piix4: Remove PCI_RMV_BASE write code > acpi_piix4: Use pci_get/set_byte > acpi_piix4: Only allow writes to PCI hotplug eject register > acpi_piix4: Disallow write to up/down PCI hotplug registers > > > docs/specs/acpi_pci_hotplug.txt | 8 +- > hw/acpi_piix4.c | 178 > ++++++++++++++++++++------------------- > 2 files changed, 95 insertions(+), 91 deletions(-)
