From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45745) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afHX5-00081V-UV for qemu-devel@nongnu.org; Sun, 13 Mar 2016 21:42:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afHX1-0001Kv-3t for qemu-devel@nongnu.org; Sun, 13 Mar 2016 21:42:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afHX0-0001Kh-V5 for qemu-devel@nongnu.org; Sun, 13 Mar 2016 21:42:51 -0400 Date: Mon, 14 Mar 2016 09:42:48 +0800 From: Fam Zheng Message-ID: <20160314014248.GA2112@ad.usersys.redhat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] about correctness of IDE emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Huaicheng Li (coperd)" Cc: qemu-devel@nongnu.org, Stefan Hajnoczi On Sun, 03/13 14:37, Huaicheng Li (coperd) wrote: > Hi all,=20 >=20 > What I=E2=80=99m confused about is that: >=20 > If one I/O is too large and may need several rounds (say 2) of DMA tran= sfers, > it seems the second round transfer begins only after the completion of = the > first part, by reading data from **IDEState**. But the IDEState info ma= y have > been changed by VCPU threads (by writing new I/Os to it) when the first > transfer finishes. From the code, I see that IDE r/w call back function= will > continue the second transfer by referencing IDEState=E2=80=99s informat= ion. Wouldn=E2=80=99t > this be problematic? Am I missing anything here? Can you give an concrete example? I/O in VCPU threads that changes IDESta= te must also take care of the DMA transfers, for example ide_reset() has blk_aio_cancel and clears s->nsectors. If an I/O handler fails to do so, = it is a bug. Fam