From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34459) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfqsM-0001Eu-Af for qemu-devel@nongnu.org; Fri, 24 May 2013 08:13:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UfqsH-0003gY-DX for qemu-devel@nongnu.org; Fri, 24 May 2013 08:13:38 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:35208) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfqsH-0003gG-7E for qemu-devel@nongnu.org; Fri, 24 May 2013 08:13:33 -0400 Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 24 May 2013 06:13:31 -0600 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 3EC611FF005A for ; Fri, 24 May 2013 06:08:21 -0600 (MDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r4OCDTUf083218 for ; Fri, 24 May 2013 06:13:29 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r4OCGVWG015379 for ; Fri, 24 May 2013 06:16:32 -0600 Message-ID: <519F5967.70801@linux.vnet.ibm.com> Date: Fri, 24 May 2013 08:13:27 -0400 From: Stefan Berger MIME-Version: 1.0 References: <1369331087-22345-1-git-send-email-coreyb@linux.vnet.ibm.com> <20130524095938.GJ21639@stefanha-thinkpad.redhat.com> In-Reply-To: <20130524095938.GJ21639@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/7] VNVRAM persistent storage List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kwolf@redhat.com, aliguori@us.ibm.com, mdroth@linux.vnet.ibm.com, Corey Bryant , qemu-devel@nongnu.org, lcapitulino@redhat.com, jschopp@linux.vnet.ibm.com, stefanha@redhat.com On 05/24/2013 05:59 AM, Stefan Hajnoczi wrote: > On Thu, May 23, 2013 at 01:44:40PM -0400, Corey Bryant wrote: >> This patch series provides VNVRAM persistent storage support that >> QEMU can use internally. The initial target user will be a software >> vTPM 1.2 backend that needs to store keys in VNVRAM and be able to >> reboot/migrate and retain the keys. >> >> This support uses QEMU's block driver to provide persistent storage >> by reading/writing VNVRAM data from/to a drive image. The VNVRAM >> drive image is provided with the -drive command line option just like >> any other drive image and the vnvram_create() API will find it. >> >> The APIs allow for VNVRAM entries to be registered, one at a time, >> each with a maximum blob size. Entry blobs can then be read/written >> from/to an entry on the drive. Here's an example of usage: >> >> VNVRAM *vnvram; >> int errcode >> const VNVRAMEntryName entry_name; >> const char *blob_w = "blob data"; >> char *blob_r; >> uint32_t blob_r_size; >> >> vnvram = vnvram_create("drive-ide0-0-0", false, &errcode); >> strcpy((char *)entry_name, "first-entry"); > VNVRAMEntryName is very prone to buffer overflow. I hope real code > doesn't use strcpy(). The cast is ugly, please don't hide the type. > >> vnvram_register_entry(vnvram, &entry_name, 1024); >> vnvram_write_entry(vnvram, &entry_name, (char *)blob_w, strlen(blob_w)+1); >> vnvram_read_entry(vnvram, &entry_name, &blob_r, &blob_r_size); > These are synchronous functions. If I/O is involved then this is a > problem: QEMU will be blocked waiting for host I/O to complete and the > big QEMU lock is held. This can cause poor guest interactivity and poor > scalability because vcpus cannot make progress, neither can the QEMU > monitor respond. The vTPM is going to run as a thread and will have to write state blobs into a bdrv. The above functions will typically be called from this thead. When I originally wrote the code, the vTPM thread could not write the blobs into bdrv directly, so I had to resort to sending a message to the main QEMU thread to write the data to the bdrv. How else could we do this? Stefan