From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55940) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRNNv-0004tJ-Uj for qemu-devel@nongnu.org; Thu, 25 Oct 2012 09:22:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TRNNr-0006q0-G8 for qemu-devel@nongnu.org; Thu, 25 Oct 2012 09:22:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRNNr-0006pb-7p for qemu-devel@nongnu.org; Thu, 25 Oct 2012 09:22:03 -0400 Message-ID: <50893CF5.60608@redhat.com> Date: Thu, 25 Oct 2012 15:21:57 +0200 From: Avi Kivity MIME-Version: 1.0 References: <50892E39.3070408@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: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. > (3) I don't think "qemu segfaults" is a good response to bad > guest behaviour so that needs fixing somehow even if we can't > model what the h/w does :-) Right, a stack trace (or a patch) would be appreciated. -- error compiling committee.c: too many arguments to function