[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v5 00/12] KVM Support for MIPS32 Processors
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 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 |
On 14/07/14 15:35, Peter Maydell wrote:
> On 14 July 2014 14:33, James Hogan <address@hidden> 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