Messages in this thread | | | Subject | Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded | From | Heinrich Schuchardt <> | Date | Thu, 5 Sep 2019 10:28:42 +0200 |
| |
On 9/5/19 10:03 AM, Marc Zyngier wrote: > [Please use my kernel.org address. My arm.com address will disappear shortly] > > On Wed, 04 Sep 2019 19:07:36 +0100, > Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: >> >> If an application tries to access memory that is not mapped, an error >> ENOSYS, "load/store instruction decoding not implemented" may occur. >> QEMU will hang with a register dump. >> >> Instead create a data abort that can be handled gracefully by the >> application running in the virtual environment. >> >> Now the virtual machine can react to the event in the most appropriate >> way - by recovering, by writing an informative log, or by rebooting. >> >> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> >> --- >> virt/kvm/arm/mmio.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/virt/kvm/arm/mmio.c b/virt/kvm/arm/mmio.c >> index a8a6a0c883f1..0cbed7d6a0f4 100644 >> --- a/virt/kvm/arm/mmio.c >> +++ b/virt/kvm/arm/mmio.c >> @@ -161,8 +161,8 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run *run, >> if (ret) >> return ret; >> } else { >> - kvm_err("load/store instruction decoding not implemented\n"); >> - return -ENOSYS; >> + kvm_inject_dabt(vcpu, kvm_vcpu_get_hfar(vcpu)); >> + return 1; > > How can you tell that the access would fault? You have no idea at that > stage (the kernel doesn't know about the MMIO ranges that userspace > handles). All you know is that you're faced with a memory access that > you cannot emulate in the kernel. Injecting a data abort at that stage > is not something that the architecture allows. > > If you want to address this, consider forwarding the access to > userspace. You'll only need an instruction decoder (supporting T1, T2, > A32 and A64) and a S1 page table walker (one per page table format, > all three of them) to emulate the access (having taken care of > stopping all the other vcpus to make sure there is no concurrent > modification of the page tables). You'll then be able to return the > result of the access back to the kernel.
If I understand you right, the problem has to be fixed in QEMU and not in KVM.
Is there an example of such a forwarding already available in QEMU?
> > Of course, the best thing would be to actually fix the guest so that > it doesn't use non-emulatable MMIO accesses. In general, that the sign > of a bug in low-level accessors.
My problem was to find out where in my guest (U-Boot running UEFI SCT) the problem occurred. With this patch U-Boot gave me the relative address in Shell.efi and I was able to locate what was wrong in U-Boot's UEFI implementation.
Thanks for reviewing.
Heinrich
| |