From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X6hM3-0000j9-2E for qemu-devel@nongnu.org; Mon, 14 Jul 2014 10:35:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X6hLx-0001wG-3C for qemu-devel@nongnu.org; Mon, 14 Jul 2014 10:35:47 -0400 Received: from mail-la0-f41.google.com ([209.85.215.41]:43536) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X6hLw-0001vx-Jy for qemu-devel@nongnu.org; Mon, 14 Jul 2014 10:35:41 -0400 Received: by mail-la0-f41.google.com with SMTP id hz20so2986120lab.28 for ; Mon, 14 Jul 2014 07:35:39 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <53C3DC14.5090403@imgtec.com> References: <1403043037-1271-1-git-send-email-james.hogan@imgtec.com> <53C3DC14.5090403@imgtec.com> From: Peter Maydell Date: Mon, 14 Jul 2014 15:35:19 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v5 00/12] KVM Support for MIPS32 Processors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: James Hogan Cc: kvm-devel , Gleb Natapov , QEMU Developers , Sanjay Lal , Christoffer Dall , Paolo Bonzini , Aurelien Jarno On 14 July 2014 14:33, James Hogan wrote: > On 10/07/14 13:17, Peter Maydell wrote: >> More generally, there doesn't really seem to be provision in the >> KVM KVM_EXIT_MMIO API for returning "this access failed". >> I guess in theory userspace could do all the "figure out how >> to adjust CPU state to do exception entry and then run VCPU", >> but that seems like quite a lot of work which the kernel already >> knows how to do; is there some way to provide a simpler API >> that lets userspace just inform the kernel that it needs to >> fault the access? > > Indeed. Paolo's idea would work well I think. A data bus error exception > would likely be the only sensible error response required other than > ignoring writes or returning a garbage value for a read (which the > current KVM MMIO API already allows). I think we should make the API at least permit returning an (architecture-specific) error code to the kernel, rather than just a single boolean "failed" response. For instance on ARM the fault status registers include a single ExT bit for classifying the type of an external abort. (The meaning of the bit is IMPDEF; on the Cortex-A15 it can be used to distinguish AXI bus DECERR ("decode error", ie the interconnect doesn't have anything attached at that address) and SLVERR ("slave error", ie there was a device at that address but it chose to reject the transaction for some reason, eg unsupported transfer size, timeout, write to read-only location, FIFO overrun or just because the device was in a bad mood.) thanks -- PMM