• C
    KVM: arm/arm64: Allow reporting non-ISV data aborts to userspace · c726200d
    Christoffer Dall 提交于
    For a long time, if a guest accessed memory outside of a memslot using
    any of the load/store instructions in the architecture which doesn't
    supply decoding information in the ESR_EL2 (the ISV bit is not set), the
    kernel would print the following message and terminate the VM as a
    result of returning -ENOSYS to userspace:
    
      load/store instruction decoding not implemented
    
    The reason behind this message is that KVM assumes that all accesses
    outside a memslot is an MMIO access which should be handled by
    userspace, and we originally expected to eventually implement some sort
    of decoding of load/store instructions where the ISV bit was not set.
    
    However, it turns out that many of the instructions which don't provide
    decoding information on abort are not safe to use for MMIO accesses, and
    the remaining few that would potentially make sense to use on MMIO
    accesses, such as those with register writeback, are not used in
    practice.  It also turns out that fetching an instruction from guest
    memory can be a pretty horrible affair, involving stopping all CPUs on
    SMP systems, handling multiple corner cases of address translation in
    software, and more.  It doesn't appear likely that we'll ever implement
    this in the kernel.
    
    What is much more common is that a user has misconfigured his/her guest
    and is actually not accessing an MMIO region, but just hitting some
    random hole in the IPA space.  In this scenario, the error message above
    is almost misleading and has led to a great deal of confusion over the
    years.
    
    It is, nevertheless, ABI to userspace, and we therefore need to
    introduce a new capability that userspace explicitly enables to change
    behavior.
    
    This patch introduces KVM_CAP_ARM_NISV_TO_USER (NISV meaning Non-ISV)
    which does exactly that, and introduces a new exit reason to report the
    event to userspace.  User space can then emulate an exception to the
    guest, restart the guest, suspend the guest, or take any other
    appropriate action as per the policy of the running system.
    Reported-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
    Signed-off-by: NChristoffer Dall <christoffer.dall@arm.com>
    Reviewed-by: NAlexander Graf <graf@amazon.com>
    Signed-off-by: NMarc Zyngier <maz@kernel.org>
    c726200d
kvm.h 45.4 KB