From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:51993)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1TaoSs-0006KI-Lu
	for qemu-devel@nongnu.org; Tue, 20 Nov 2012 09:06:20 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1TaoSi-0004AC-Db
	for qemu-devel@nongnu.org; Tue, 20 Nov 2012 09:06:14 -0500
Received: from mail-bk0-f45.google.com ([209.85.214.45]:43756)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1TaoSi-00049o-6U
	for qemu-devel@nongnu.org; Tue, 20 Nov 2012 09:06:04 -0500
Received: by mail-bk0-f45.google.com with SMTP id jk13so1413842bkc.4
	for <qemu-devel@nongnu.org>; Tue, 20 Nov 2012 06:06:03 -0800 (PST)
Date: Tue, 20 Nov 2012 15:06:01 +0100
From: Stefan Hajnoczi <stefanha@gmail.com>
Message-ID: <20121120140601.GA28789@stefanha-thinkpad.redhat.com>
References: <cover.1353335052.git.jan.kiszka@siemens.com>
	<02a783361c36ed54647b6b34f5c1243c2a94bbe6.1353335052.git.jan.kiszka@siemens.com>
	<20121120132732.GG27378@stefanha-thinkpad.redhat.com>
	<50AB8783.5060508@siemens.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <50AB8783.5060508@siemens.com>
Subject: Re: [Qemu-devel] [PATCH 2/2] Add AT24Cxx I2C EEPROM device model
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: Jan Kiszka <jan.kiszka@siemens.com>
Cc: qemu-devel <qemu-devel@nongnu.org>

On Tue, Nov 20, 2012 at 02:37:07PM +0100, Jan Kiszka wrote:
> On 2012-11-20 14:27, Stefan Hajnoczi wrote:
> > On Mon, Nov 19, 2012 at 03:24:39PM +0100, Jan Kiszka wrote:
> >> +static void at24_flush_transfer_buffer(AT24State *s)
> >> +{
> >> +    if (s->cached_sector < 0 || !s->cache_dirty) {
> >> +        return;
> >> +    }
> >> +    bdrv_write(s->bs, s->cached_sector, s->sector_buffer, 1);
> > [...]
> >> +static int at24_cache_sector(AT24State *s, int sector)
> >> +{
> >> +    int ret;
> >> +
> >> +    if (s->cached_sector == sector) {
> >> +        return 0;
> >> +    }
> >> +    ret = bdrv_read(s->bs, sector, s->sector_buffer, 1);
> > 
> > Can you use bdrv_aio_writev()/bdrv_aio_readv()?  We should avoid adding
> > new synchronous block I/O.  Because it forces us to run a nested event
> > loop that blocks the guest until I/O completes.
> 
> The call is synchronous as the I2C bus model is as well. How do I model
> this with bdrv_aio_*?

The bus model needs to be asynchronous.

There are still a few bdrv_read()/bdrv_write() users in hw/ today so
it's not the end of the world if you can't make it async, but it means
someone else will have to do the work eventually :(.

Stefan