From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41496) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIbi9-0003WN-AS for qemu-devel@nongnu.org; Wed, 26 Feb 2014 05:27:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIbi4-0002WH-3f for qemu-devel@nongnu.org; Wed, 26 Feb 2014 05:27:33 -0500 Received: from mail-ie0-f170.google.com ([209.85.223.170]:39809) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIbi3-0002WD-V0 for qemu-devel@nongnu.org; Wed, 26 Feb 2014 05:27:28 -0500 Received: by mail-ie0-f170.google.com with SMTP id y20so481904ier.29 for ; Wed, 26 Feb 2014 02:27:27 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1393347170-28502-1-git-send-email-a.rigo@virtualopensystems.com> <1393347170-28502-5-git-send-email-a.rigo@virtualopensystems.com> Date: Wed, 26 Feb 2014 11:27:27 +0100 Message-ID: From: alvise rigo Content-Type: multipart/alternative; boundary=20cf303349fdbec5ed04f34ca680 Subject: Re: [Qemu-devel] [RFC 4/4] Relevant changes to enable KVM to TCG migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "tech@virtualopensystems.com" , QEMU Developers --20cf303349fdbec5ed04f34ca680 Content-Type: text/plain; charset=ISO-8859-1 Improvements of cpreg emulation apart, we will still need to tackle with the great amount of registers not migrated because generated by a wildcarded register; some of these registers are in fact migrated by KVM. I think that the idea of keeping a reference to the generator register (i.e. the only register which is migrated in a wildcarded case) could be considered to handle the migration. alvise On Wed, Feb 26, 2014 at 11:04 AM, Peter Maydell wrote: > On 26 February 2014 10:02, alvise rigo > wrote: > > I agree that this is a sort of workaround, but it seems to me that a > > proper solution is not possible without changing the ideas contemplated > > now in the migration code. > > Are we willing to accept some major changes in the code to embrace > > this type of migration? > > Well, the migration code as it stands is in theory supposed to cope > with KVM<->TCG migration. I would expect that we'd need to improve > a number of places where our TCG cpreg emulation is wrong. > > thanks > -- PMM > --20cf303349fdbec5ed04f34ca680 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Improvements of cpreg emulation apart, we w= ill still need to tackle
with the great amount of registers not migrated= because generated
by a wildcarded register; some of these registe= rs are in fact migrated
by KVM. I think that the idea of keeping a reference
to the generator register (i.e. the only register which is migrated i= n a
wildcarded case) could be considered to handle the migration.<= br>
alvise


On Wed, Feb 26, 2014 at 11:04 AM, Peter Maydell <peter.maydell@lina= ro.org> wrote:
On 26 February 2014 10:02, alvise rigo <a.rigo@virtualopensystems.com> wrot= e:
> I agree that this is a sort of workaround, but it seems to me that a > proper solution is not possible without changing the ideas contemplate= d
> now in the migration code.
> Are we willing to accept some major changes in the code to embrace
> this type of migration?

Well, the migration code as it stands is in theory supposed to cope with KVM<->TCG migration. I would expect that we'd need to improv= e
a number of places where our TCG cpreg emulation is wrong.

thanks
-- PMM

--20cf303349fdbec5ed04f34ca680--