From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpFVW-00089u-9U for qemu-devel@nongnu.org; Mon, 04 May 2015 08:30:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YpFVS-0008GX-71 for qemu-devel@nongnu.org; Mon, 04 May 2015 08:29:58 -0400 Date: Mon, 4 May 2015 14:29:42 +0200 From: Kevin Wolf Message-ID: <20150504122942.GG3676@noname.str.redhat.com> References: <1430417242-11859-1-git-send-email-jsnow@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1430417242-11859-1-git-send-email-jsnow@redhat.com> Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v3 0/9] ahci: enable migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow Cc: marc.mari.barcelo@gmail.com, pbonzini@redhat.com, stefanha@redhat.com, qemu-devel@nongnu.org, qemu-block@nongnu.org Am 30.04.2015 um 20:07 hat John Snow geschrieben: > The day we all feared is here, and I am proposing we allow the migration > of the AHCI device tentatively for the 2.4 development window. > > There are some more NCQ migration tests are needed, but I felt that it was > important to get migration enabled as close to the start of the 2.4 > development window as possible. > > If the NCQ patches don't pan out by the time the 2.4 freeze occurs, we can > revert the migration boolean and add a conditional around the ahci tests > that rely on the migration feature being enabled. > > I am justifying this checkin based on a series of ping-pong > migration tests I ran under heavy load (using google's stressapptest) > and saw over 300 successful migrations without a single failure. > > This series does a few things: > (1) Add migration facilities to libqos > (2) Enable AHCI and ICH9 migration > (3) Add a series of migration tests to ahci-test Reviewed-by: Kevin Wolf I think besides the NCQ tests, we'll definitely also want to test migration with READ DMA in flight (this series tests only WRITE DMA and FLUSH CACHE). Probably also discard. Nice to have, but less important, would be the other variants that exist, like the EXT version of each command, and READ/WRITE SECTOR. But all of that can be added in a follow-up series, it's not a reason to hold up what's already there. Kevin