From: Andrew Jones <drjones@redhat.com>
To: Beata Michalska <beata.michalska@linaro.org>
Cc: qemu-devel@nongnu.org, qemu-arm@nongnu.org, pbonzini@redhat.com,
kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH v4 1/2] target/arm: kvm: Handle DABT with no valid ISS
Date: Mon, 23 Mar 2020 13:44:05 +0100 [thread overview]
Message-ID: <20200323124405.xdv56zplli23sl46@kamzik.brq.redhat.com> (raw)
In-Reply-To: <20200323113227.3169-2-beata.michalska@linaro.org>
On Mon, Mar 23, 2020 at 11:32:26AM +0000, Beata Michalska wrote:
> On ARMv7 & ARMv8 some load/store instructions might trigger a data abort
> exception with no valid ISS info to be decoded. The lack of decode info
> makes it at least tricky to emulate those instruction which is one of the
> (many) reasons why KVM will not even try to do so.
>
> Add support for handling those by requesting KVM to inject external
> dabt into the quest.
>
> Signed-off-by: Beata Michalska <beata.michalska@linaro.org>
> ---
> target/arm/cpu.h | 2 ++
> target/arm/kvm.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> target/arm/kvm_arm.h | 11 +++++++++++
> 3 files changed, 67 insertions(+)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 4ffd991..4f834c1 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -560,6 +560,8 @@ typedef struct CPUARMState {
> uint64_t esr;
> } serror;
>
> + uint8_t ext_dabt_pending; /* Request for injecting ext DABT */
> +
> /* State of our input IRQ/FIQ/VIRQ/VFIQ lines */
> uint32_t irq_line_state;
>
> diff --git a/target/arm/kvm.c b/target/arm/kvm.c
> index 85860e6..c088589 100644
> --- a/target/arm/kvm.c
> +++ b/target/arm/kvm.c
> @@ -39,6 +39,7 @@ const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
>
> static bool cap_has_mp_state;
> static bool cap_has_inject_serror_esr;
> +static bool cap_has_inject_ext_dabt;
>
> static ARMHostCPUFeatures arm_host_cpu_features;
>
> @@ -244,6 +245,16 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> ret = -EINVAL;
> }
>
> + if (kvm_check_extension(s, KVM_CAP_ARM_NISV_TO_USER)) {
> + if (kvm_vm_enable_cap(s, KVM_CAP_ARM_NISV_TO_USER, 0)) {
> + warn_report("Failed to enable DABT NISV cap");
Shouldn't this be an error? If KVM says it has KVM_CAP_ARM_NISV_TO_USER,
then I think it should always work to enable it, unless userspace passes
the wrong flags. Currently flags must be zero, but if they were to change
then we'll need to add the flags to vmstate and fail migration when they
aren't compatible, and I guess that failure would occur here.
> + } else {
> + /* Set status for supporting the external dabt injection */
> + cap_has_inject_ext_dabt = kvm_check_extension(s,
> + KVM_CAP_ARM_INJECT_EXT_DABT);
> + }
> + }
> +
> return ret;
> }
>
> @@ -703,9 +714,16 @@ int kvm_put_vcpu_events(ARMCPU *cpu)
> events.exception.serror_esr = env->serror.esr;
> }
>
> + if (cap_has_inject_ext_dabt) {
> + events.exception.ext_dabt_pending = env->ext_dabt_pending;
> + }
> +
> ret = kvm_vcpu_ioctl(CPU(cpu), KVM_SET_VCPU_EVENTS, &events);
> if (ret) {
> error_report("failed to put vcpu events");
> + } else {
> + /* Clear instantly if the call was successful */
> + env->ext_dabt_pending = 0;
> }
>
> return ret;
> @@ -819,6 +837,11 @@ int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run)
> ret = EXCP_DEBUG;
> } /* otherwise return to guest */
> break;
> + case KVM_EXIT_ARM_NISV:
> + /* External DABT with no valid iss to decode */
> + ret = kvm_arm_handle_dabt_nisv(cs, run->arm_nisv.esr_iss,
> + run->arm_nisv.fault_ipa);
> + break;
> default:
> qemu_log_mask(LOG_UNIMP, "%s: un-handled exit reason %d\n",
> __func__, run->exit_reason);
> @@ -953,3 +976,34 @@ int kvm_arch_msi_data_to_gsi(uint32_t data)
> {
> return (data - 32) & 0xffff;
> }
> +
> +int kvm_arm_handle_dabt_nisv(CPUState *cs, uint64_t esr_iss,
> + uint64_t fault_ipa)
> +{
> + ARMCPU *cpu = ARM_CPU(cs);
> + CPUARMState *env = &cpu->env;
> +
> + /*
> + * ISS [23:14] is invalid so there is a limited info
> + * on what has just happened so the only *useful* thing that can
> + * be retrieved from ISS is WnR & DFSC (though in some cases WnR
> + * might be less of a value as well)
> + */
> +
> + /*
> + * Set pending ext dabt and trigger SET_EVENTS so that
> + * KVM can inject the abort
> + */
> + if (cap_has_inject_ext_dabt) {
> + kvm_cpu_synchronize_state(cs);
I guess this is just an expensive 'vcpu_dirty=true', which the comment
above justifies, but not super clearly. Can you try to clarify the
comment some more? I also wonder if we shouldn't add a KVM function
that just marks a vcpu dirty, rather than fetching all registers.
> + env->ext_dabt_pending = 1;
> + } else {
> + error_report("Data abort exception triggered by guest memory access "
> + "at physical address: 0x" TARGET_FMT_lx,
> + (target_ulong)fault_ipa);
> + error_printf("KVM unable to emulate faulting instruction.\n");
> + return -1;
> + }
> +
> + return 0;
> +}
> diff --git a/target/arm/kvm_arm.h b/target/arm/kvm_arm.h
> index ae9e075..39472d5 100644
> --- a/target/arm/kvm_arm.h
> +++ b/target/arm/kvm_arm.h
> @@ -450,6 +450,17 @@ struct kvm_guest_debug_arch;
> void kvm_arm_copy_hw_debug_data(struct kvm_guest_debug_arch *ptr);
>
> /**
> + * kvm_arm_handle_dabt_nisv:
> + * @cs: CPUState
> + * @esr_iss: ISS encoding (limited) for the exception from Data Abort
> + * ISV bit set to '0b0' -> no valid instruction syndrome
> + * @fault_ipa: faulting address for the synch data abort
> + *
> + * Returns: 0 if the exception has been handled, < 0 otherwise
> + */
> +int kvm_arm_handle_dabt_nisv(CPUState *cs, uint64_t esr_iss,
> + uint64_t fault_ipa);
> +/**
> * its_class_name:
> *
> * Return the ITS class name to use depending on whether KVM acceleration
> --
> 2.7.4
>
Thanks,
drew
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
next prev parent reply other threads:[~2020-03-23 12:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-23 11:32 [PATCH v4 0/2] target/arm: kvm: Support for KVM DABT with no valid ISS Beata Michalska
2020-03-23 11:32 ` [PATCH v4 1/2] target/arm: kvm: Handle " Beata Michalska
2020-03-23 12:44 ` Andrew Jones [this message]
2020-03-25 15:15 ` Beata Michalska
2020-04-17 10:39 ` Peter Maydell
2020-04-17 13:10 ` Andrew Jones
2020-04-18 22:56 ` Beata Michalska
2020-04-24 12:16 ` Dr. David Alan Gilbert
2020-04-24 12:51 ` Peter Maydell
2020-04-25 9:24 ` Paolo Bonzini
2020-04-27 6:18 ` Andrew Jones
2020-03-23 11:32 ` [PATCH v4 2/2] target/arm: kvm: Handle potential issue with dabt injection Beata Michalska
2020-03-23 18:44 ` Richard Henderson
2020-03-25 15:16 ` Beata Michalska
2020-04-03 8:44 ` Andrew Jones
2020-04-07 11:24 ` Peter Maydell
2020-04-07 11:32 ` Beata Michalska
2020-04-07 11:31 ` Beata Michalska
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200323124405.xdv56zplli23sl46@kamzik.brq.redhat.com \
--to=drjones@redhat.com \
--cc=beata.michalska@linaro.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=pbonzini@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).