From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38534) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRNwM-0002ya-3N for qemu-devel@nongnu.org; Thu, 25 Oct 2012 09:57:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TRNwF-0002N5-R9 for qemu-devel@nongnu.org; Thu, 25 Oct 2012 09:57:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47690) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRNwF-0002Mt-It for qemu-devel@nongnu.org; Thu, 25 Oct 2012 09:57:35 -0400 Message-ID: <5089454A.2050708@redhat.com> Date: Thu, 25 Oct 2012 15:57:30 +0200 From: Avi Kivity MIME-Version: 1.0 References: <50892E39.3070408@redhat.com> <50893CF5.60608@redhat.com> <5089418C.2000003@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v1 8/8] usb/ehci: Put RAM in undefined MMIO regions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: vineshp@xilinx.com, Peter Crosthwaite , qemu-devel@nongnu.org, john.williams@xilinx.com, Gerd Hoffmann , edgar.iglesias@gmail.com On 10/25/2012 03:50 PM, Peter Maydell wrote: > On 25 October 2012 14:41, Avi Kivity wrote: >> On 10/25/2012 03:28 PM, Peter Maydell wrote: >>> On 25 October 2012 14:21, Avi Kivity wrote: >>>> You could easily have the top-level container have ->ops that generate >>>> an exception. >>> >>> Ah, yes, there's an 'accepts' callback. (That's kind of awkward >>> as an API because it means your decode logic gets spread between >>> read, write and accept: there are some devices where it would be >>> nice to have the 'default:' case of the address switch say "unknown >>> offset, raise decode error". If the read callback took a uint64_t* >>> rather than returning the read data, we could make both read and >>> write return a success/decode-error type of status result.) >> >> I actually forgot about ->accepts(). But it isn't needed for this use >> case, just have the lowest priority region (the container) implement >> ->read/write that generate the exception > > I don't understand this -- read/write don't have any way of saying > "please generate an exception". The only thing I can see in the > API that does that is returning false from accepts(). read/write can call anything. So if the SoC code installs the lowest region, it has access to whatever mechanisms generate the exceptions. (it may not have access to CPUState though). > >> wrt decode duplication, I've been thinking of a single ->service() >> callback that accepts a Transaction argument, including all the details >> (offset, data, and direction). > > If we do this we should make sure that the Transaction allows us to > include CPU-architecture dependent info -- for ARM we would want to > model transaction attributes like 'secure/nonsecure', 'privileged/nonpriv', > 'instruction/data', etc. You also want to include in the transaction > attributes who the master end of this transaction is (so a slave > can distinguish accesses from a particular CPU core in a cluster, > for instance). This would allow us to remove some of the current > nasty hacks where devices reach into the CPUArchState to retrieve > info that should ideally be modelled as part of the bus transaction. Sounds like good arguments for another sweep. -- error compiling committee.c: too many arguments to function