From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43485) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSv2p-0002WA-0I for qemu-devel@nongnu.org; Sun, 06 Oct 2013 16:35:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VSv2g-0004BN-Kg for qemu-devel@nongnu.org; Sun, 06 Oct 2013 16:35:14 -0400 Received: from mail-ee0-x22d.google.com ([2a00:1450:4013:c00::22d]:61841) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VSv2g-00048u-E8 for qemu-devel@nongnu.org; Sun, 06 Oct 2013 16:35:06 -0400 Received: by mail-ee0-f45.google.com with SMTP id c50so2825545eek.32 for ; Sun, 06 Oct 2013 13:35:05 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5251C96D.1020709@redhat.com> Date: Sun, 06 Oct 2013 22:34:53 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1380807975-13266-1-git-send-email-pbonzini@redhat.com> <20131003135404.GA1267@redhat.com> <524D9426.20707@redhat.com> <20131003165417.GA4616@redhat.com> <524DA0F6.3050007@redhat.com> <20131006182806.GA16531@redhat.com> In-Reply-To: <20131006182806.GA16531@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/4] qdev: switch reset to post-order, clean up PCI reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org Il 06/10/2013 20:28, Michael S. Tsirkin ha scritto: > > > > For each PCI device I tried creating a VM with an instance of it (a few > > > > devices at a time), and did VM resets. Earlier versions were tested by > > > > the guy who reported the SCSI problems. > > > > > > x86 kvm only? > > > > Yes. > > Hmm, I'm not sure that's enough for this kind of change. I'll do more tests though, from looking at the source code, I'm not sure what could happen depending on the host bridge. To make it clearer, the difference is that pre-patch you have device-level reset for device 1 bus-level reset for device 1 device-level reset for device 2 bus-level reset for device 2 device-level reset for device 3 bus-level reset for device 3 and afterwards you have device-level reset for device 1 device-level reset for device 2 device-level reset for device 3 bus-level reset for device 1 bus-level reset for device 2 bus-level reset for device 3 I could also preserve exactly the same semantics if you prefer. The patch is a bit more complicated, but it's doable. Paolo