From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37649) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFjX9-0005Nq-Km for qemu-devel@nongnu.org; Thu, 05 Apr 2012 06:03:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFjX3-0000zk-27 for qemu-devel@nongnu.org; Thu, 05 Apr 2012 06:03:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30427) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFjX2-0000yW-Pw for qemu-devel@nongnu.org; Thu, 05 Apr 2012 06:03:08 -0400 Date: Thu, 5 Apr 2012 13:03:14 +0300 From: "Michael S. Tsirkin" Message-ID: <20120405100314.GF28808@redhat.com> References: <20120405050848.31461.10826.stgit@bling.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120405050848.31461.10826.stgit@bling.home> Subject: Re: [Qemu-devel] [PATCH 0/5] PCI hotplug fixes/cleanup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: aliguori@us.ibm.com, gleb@redhat.com, jbaron@redhat.com, qemu-devel@nongnu.org, yamahata@valinux.co.jp, kraxel@redhat.com, pbonzini@redhat.com, imammedo@redhat.com, aurelien@aurel32.net 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 > 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(-)