From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=57606 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PJS5N-0002vX-8J
	for qemu-devel@nongnu.org; Fri, 19 Nov 2010 09:37:10 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1PJS5M-0000gD-3O
	for qemu-devel@nongnu.org; Fri, 19 Nov 2010 09:37:09 -0500
Received: from mx1.redhat.com ([209.132.183.28]:42762)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1PJS5L-0000g5-Sm
	for qemu-devel@nongnu.org; Fri, 19 Nov 2010 09:37:08 -0500
Message-ID: <4CE68B7A.3060503@redhat.com>
Date: Fri, 19 Nov 2010 15:36:42 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 00/10] AHCI emulation support v2
References: <1290050875-23848-1-git-send-email-agraf@suse.de>
	<4CE52996.9060102@redhat.com>
	<D17ADFDD-6147-408C-8A83-FA46AC69784D@suse.de>
	<4CE64036.4040206@redhat.com>
	<61136B5B-9282-4667-9AD8-545456CD7FDB@suse.de>
In-Reply-To: <61136B5B-9282-4667-9AD8-545456CD7FDB@suse.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexander Graf <agraf@suse.de>
Cc: Kevin Wolf <kwolf@redhat.com>, Juan Quintela <quintela@redhat.com>, Joerg Roedel <Joerg.Roedel@amd.com>, QEMU-devel Developers <qemu-devel@nongnu.org>, Stefan Hajnoczi <stefanha@gmail.com>, "tj@kernel.org" <tj@kernel.org>, Sebastian Herbszt <herbszt@gmx.de>, Roland Elek <elek.roland@gmail.com>

   Hi,

> Also to catch up on Gerd's point - whatever refactoring we do, we
> will basically have to break migration. There is no way we can change
> all the internal state and structure and maintain binary
> compatibility with the old save states.

On the other hand it would be a *real* pity to drag the ide migration 
mess into ahci ...

Ideally each ide-drive should save its state itself, and likewise each 
ide/ahci controller.  Maybe it would be a good first step to move to 
such a model in the savevm data format, but keep the current ide data 
structures for a while so we can easily accept migrations in the old 
savevm format for the time being.

Then a relase or two away from today we'll drop support for the old ide 
savevm format, so we can finally tranform the ide data structures to 
something sane?

Juan?  Comments?

cheers,
   Gerd