From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:54324)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Xb7iF-0007Dk-HL
	for qemu-devel@nongnu.org; Mon, 06 Oct 2014 08:48:33 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Xb7i9-000831-D2
	for qemu-devel@nongnu.org; Mon, 06 Oct 2014 08:48:27 -0400
Received: from mx1.redhat.com ([209.132.183.28]:14546)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Xb7i9-00082k-4f
	for qemu-devel@nongnu.org; Mon, 06 Oct 2014 08:48:21 -0400
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s96CmIFf012419
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=FAIL)
	for <qemu-devel@nongnu.org>; Mon, 6 Oct 2014 08:48:19 -0400
Message-ID: <54328F8F.6010109@redhat.com>
Date: Mon, 06 Oct 2014 14:48:15 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1410953992-14542-1-git-send-email-ghammer@redhat.com>
	<20141006090657.GA18003@redhat.com>
In-Reply-To: <20141006090657.GA18003@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 0/2 V5] Virtual Machine Generation ID
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/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: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Daniel P. Berrange" <berrange@redhat.com>, Gal Hammer <ghammer@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>, qemu-devel@nongnu.org

Il 06/10/2014 11:06, Daniel P. Berrange ha scritto:
> Now this can largely be accomplished by libvirt by simply changing the
> value of the -vmgenid command line parameter, because most of these
> scenarios involve the spawning of a new QEMU process. The exception
> I think is when a running guest is reverted to a previous snapshot,
> because that is done via a monitor command and not restarting QEMU.
> So for this VM Generation ID work to be considered complete we need
> to have a way to dynamically change the VM generation ID on the fly,
> atomatically with reverting snapshots from the POV of the guest.
> eg we must load the snapshot state, change the generation ID, and
> only then start CPUs again.
> 
> IOW I think this patch series is incomplete wrt the Microsoft spec
> on generation ID semantics.

I think this should not be a problem, as long as there is an idea of how
to implement on-the-fly changes to the vmgenid.

Gal, do you know how to find back the address of the VM generation ID?
Can we put the offset into the DSDT in the migration stream, and then
find the ACPI tables in the f-segment at post_load time?

Paolo