From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35339) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0IQn-0002nH-Ac for qemu-devel@nongnu.org; Sun, 04 Sep 2011 15:32:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0IQj-0001OS-BB for qemu-devel@nongnu.org; Sun, 04 Sep 2011 15:32:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45946) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0IQj-0001OB-30 for qemu-devel@nongnu.org; Sun, 04 Sep 2011 15:32:33 -0400 Date: Sun, 4 Sep 2011 22:32:58 +0300 From: "Michael S. Tsirkin" Message-ID: <20110904193258.GA13640@redhat.com> References: <20110831143551.127339744@linux.vnet.ibm.com> <20110831143621.799480525@linux.vnet.ibm.com> <20110901173225.GH10989@redhat.com> <4E603724.7010405@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E603724.7010405@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH V8 08/14] Introduce file lock for the block layer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Berger Cc: chrisw@redhat.com, anbang.ruan@cs.ox.ac.uk, qemu-devel@nongnu.org, rrelyea@redhat.com, alevy@redhat.com, andreas.niederl@iaik.tugraz.at, serge@hallyn.com On Thu, Sep 01, 2011 at 09:53:40PM -0400, Stefan Berger wrote: > >Generally, what all other devices do is perform validation > >as the last step in migration when device state > >is restored. On failure, management can decide what to do: > >retry migration or restart on source. > > > >Why is TPM special and needs to be treated differently? > > > > > > ... > > More detail: Typically one starts out with an empty QCoW2 file > created via qemu-img. Once Qemu starts and initializes the > libtpms-based TPM, it tries to read existing state from that QCoW2 > file. Since there is no state stored in the QCoW2, the TPM will > start initializing itself to an initial 'blank' state. So it looks like the problem is you access the file when guest isn't running. Delaying the initialization until the guest actually starts running will solve the problem in a way that is more consistent with other qemu devices. -- MST