From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57747) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWakN-0008Vz-4y for qemu-devel@nongnu.org; Mon, 21 May 2012 18:06:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWakL-0001sV-96 for qemu-devel@nongnu.org; Mon, 21 May 2012 18:06:34 -0400 Received: from mail-bk0-f45.google.com ([209.85.214.45]:44888) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWakK-0001s6-Pq for qemu-devel@nongnu.org; Mon, 21 May 2012 18:06:33 -0400 Received: by bkwj10 with SMTP id j10so5213365bkw.4 for ; Mon, 21 May 2012 15:06:29 -0700 (PDT) Date: Tue, 22 May 2012 00:06:25 +0200 From: "Edgar E. Iglesias" Message-ID: <20120521220625.GA20808@zapo> References: <27874590.608345.1337095907076.JavaMail.www@wwinf8306> <4FB28591.4090709@suse.de> <189253069.454583.1337155108168.JavaMail.www@wwinf8304> <842600711.2527751.1337584877321.JavaMail.www@wwinf8221> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] Get current env within io_handler ? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Peter Maydell , qemu-devel@nongnu.org, "nicolas.sauzede" On Mon, May 21, 2012 at 06:40:38PM +0000, Blue Swirl wrote: > On Mon, May 21, 2012 at 6:28 PM, Peter Maydell wrote: > > On 21 May 2012 19:08, Blue Swirl wrote: > >> On Mon, May 21, 2012 at 10:36 AM, Peter Maydell > >> wrote: > >>> I think it would be nice to have this in upstream qemu; however adding > >>> transaction properties to the IO interface would be quite tricky I > >>> suspect... > >> > >> This is limited to CPU and CPU local bus devices (not generic like > >> PCI), so there could be an out of band mechanism to get/set the > >> additional data. > > > > What's your definition of "generic" here? AMBA isn't particularly > > limited to CPU local bus devices either, really (for instance > > the connection between a versatile express CPU daughterboard > > and the motherboard includes an AMBA AXI bus). > > I'd expect that only AMBA devices (ARM specific) would care about the > properties, while for example NE2k could not care less. > > > > >> For example store in op_helper.c could use > >> cpu_set_amba_properties(...) before the store and afterwards > >> cpu_get_amba_reply(...). > > > > We really don't want to do two helper function calls for every > > load or store! If you're going to implement them at all then > > you need a more efficient implementation than that... > > How about lazy evaluation: generate the properties/evaluate reply only > if the device wants them via > device_get_properties()/device_set_reply(). Then the transaction > overhead could be ignored by everyone if not needed. Hi, This party came up when evaluating the mem API. IMO, it would be nice to have a way for the master (CPU, DMA or whatever) to be able to pass attributes with accesses. Possibly also for the device to return return codes (or error codes) as a result of the access. The details may be bus specific (AMBA, OCP, etc) but the concept is not. Unfortunately, I'm afraid it would involve quite a bit of changes to the code again unless someone comes up with a smart way of doing it... Cheers