From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Hogan Subject: Re: [Qemu-devel] [PATCH v5 00/12] KVM Support for MIPS32 Processors Date: Mon, 14 Jul 2014 16:50:36 +0100 Message-ID: <53C3FC4C.3090703@imgtec.com> References: <1403043037-1271-1-git-send-email-james.hogan@imgtec.com> <53C3DC14.5090403@imgtec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: QEMU Developers , kvm-devel , Gleb Natapov , Sanjay Lal , "Paolo Bonzini" , Aurelien Jarno , Christoffer Dall To: Peter Maydell Return-path: Received: from mailapp01.imgtec.com ([195.59.15.196]:16685 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932111AbaGNPuj (ORCPT ); Mon, 14 Jul 2014 11:50:39 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 14/07/14 15:35, Peter Maydell wrote: > 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.) Agreed (I wasn't suggesting a bool, just thinking out loud about how mips would use that arch specific value :-) ). Cheers James