From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ufu5Q-0004cU-EU for qemu-devel@nongnu.org; Fri, 24 May 2013 11:39:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ufu5L-0003un-4h for qemu-devel@nongnu.org; Fri, 24 May 2013 11:39:20 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:54424) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ufu5K-0003ua-PK for qemu-devel@nongnu.org; Fri, 24 May 2013 11:39:15 -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 09:39:13 -0600 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 9CEBD6E8060 for ; Fri, 24 May 2013 11:39:07 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r4OFdBOL312090 for ; Fri, 24 May 2013 11:39:11 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r4OFdAqn006972 for ; Fri, 24 May 2013 11:39:10 -0400 Message-ID: <519F899D.3090604@linux.vnet.ibm.com> Date: Fri, 24 May 2013 11:39:09 -0400 From: Corey Bryant MIME-Version: 1.0 References: <1369331087-22345-1-git-send-email-coreyb@linux.vnet.ibm.com> <20130524095938.GJ21639@stefanha-thinkpad.redhat.com> <519F5967.70801@linux.vnet.ibm.com> <20130524123625.GA24111@stefanha-thinkpad.redhat.com> In-Reply-To: <20130524123625.GA24111@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, Stefan Berger , Stefan Hajnoczi , mdroth@linux.vnet.ibm.com, qemu-devel@nongnu.org, jschopp@linux.vnet.ibm.com, lcapitulino@redhat.com On 05/24/2013 08:36 AM, Stefan Hajnoczi wrote: > On Fri, May 24, 2013 at 08:13:27AM -0400, Stefan Berger wrote: >> 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? > > How else: use asynchronous APIs like bdrv_aio_writev() or the coroutine > versions (which eliminate the need for callbacks) like bdrv_co_writev(). > > I'm preparing patches that allow the QEMU block layer to be used safely > outside the QEMU global mutex. Once this is possible it would be okay > to use synchronous methods. Ok thanks. I'll use aio APIs next time around. Just to be clear, does "eliminating the callback" mean I don't have to use a bottom-half if I use coroutine reads/writes? -- Regards, Corey Bryant