From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=33223 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Q8Va0-0001PV-Sc
	for qemu-devel@nongnu.org; Sat, 09 Apr 2011 06:39:49 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <amit.shah@redhat.com>) id 1Q8VZz-0000J2-VE
	for qemu-devel@nongnu.org; Sat, 09 Apr 2011 06:39:48 -0400
Received: from mx1.redhat.com ([209.132.183.28]:29870)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <amit.shah@redhat.com>) id 1Q8VZz-0000Ix-LS
	for qemu-devel@nongnu.org; Sat, 09 Apr 2011 06:39:47 -0400
Date: Sat, 9 Apr 2011 16:06:58 +0530
From: Amit Shah <amit.shah@redhat.com>
Message-ID: <20110409103658.GA3955@amit-x200.redhat.com>
References: <cover.1302246567.git.amit.shah@redhat.com>
	<8c4effc5d537fe0a35791e2f970ede8ed400b5bd.1302246567.git.amit.shah@redhat.com>
	<4D9F0E45.6000005@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4D9F0E45.6000005@redhat.com>
Subject: [Qemu-devel] Re: [PATCH 3/5] atapi: GESN: Spin off No Event
 Available handling into own function
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Juan Quintela <quintela@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com>, Markus Armbruster <armbru@redhat.com>, qemu list <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>

On (Fri) 08 Apr 2011 [15:31:49], Kevin Wolf wrote:
> Am 08.04.2011 09:15, schrieb Amit Shah:
> > Handle GET_EVENT_STATUS_NOTIFICATION's No Event Available status in its
> > own function.
> > 
> > Also ensure the buffer the driver sent us is big enough to fill in all
> > the data we have -- else just fill in as much as the buffer can hold.
> 
> This is unnecessary and in fact none of the IDE code does this.
> s->io_buffer isn't guest memory, but an internal buffer that is
> allocated like this:
> 
> s->io_buffer = qemu_memalign(2048, IDE_DMA_BUF_SECTORS*512 + 4);

OK - so all the code paths will be much easier then.

But by my reading of (the kernel) code, it looks as if the kernel
allocates the memory and passes it on.  What am I missing?

> So that's more than enough for storing four bytes. ide_atapi_cmd_reply()
> takes care of making only max_size bytes visible to the guest.

OK - but in some cases we just do a ide_set_irq() instead of
ide_atapi_cmd_reply() so what happens in that case?

		Amit