From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59111) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRNgy-0000jw-3E for qemu-devel@nongnu.org; Thu, 25 Oct 2012 09:41:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TRNgo-0004oa-EJ for qemu-devel@nongnu.org; Thu, 25 Oct 2012 09:41:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44675) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRNgo-0004oW-4g for qemu-devel@nongnu.org; Thu, 25 Oct 2012 09:41:38 -0400 Message-ID: <5089418C.2000003@redhat.com> Date: Thu, 25 Oct 2012 15:41:32 +0200 From: Avi Kivity MIME-Version: 1.0 References: <50892E39.3070408@redhat.com> <50893CF5.60608@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:28 PM, Peter Maydell wrote: > On 25 October 2012 14:21, Avi Kivity wrote: >> On 10/25/2012 03:12 PM, Peter Maydell wrote: >>> (2) what should the memory system do for accesses where there is >>> no memory region? This is really system specific as it depends >>> what the bus fabric does. For ARM the usual thing would be to >>> generate a decode error response which will result in the guest >>> CPU taking a data abort or prefetch abort. I don't think our >>> memory system currently has any way of saying "for this access >>> generate an exception"... >>> >> >> 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. If some other region decodes, the container region will be ignored, if nothing decodes, you get your exception. 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). We may also do something like MemoryRegionPortio, but not hacky, that lets you have a MemoryRegion for each register. That means that instead of writing two large functions that duplicates the decode, you write one function per register, and switch on transfer direction. -- error compiling committee.c: too many arguments to function