Re: [PATCH 2/2] arm64/kvm: survive unknown traps from guests
On Mon, Feb 20, 2017 at 12:30:12PM +, Mark Rutland wrote:
> Currently we BUG() if we see an ESR_EL2.EC value we don't recognise. As
> configurable disables/enables are added to the architecture (controlled
> by RES1/RES0 bits respectively), with associated synchronous exceptions,
> it may be possible for a guest to trigger exceptions with classes that
> we don't recognise.
>
> While we can't service these exceptions in a manner useful to the guest,
> we can avoid bringing down the host. Per ARM DDI 0487A.k_iss10775, page
> D7-1937, EC values within the range 0x00 - 0x2c are reserved for future
> use with synchronous exceptions, and EC values within the range 0x2d -
> 0x3f may be used for either synchronous or asynchronous exceptions.
>
> The patch makes KVM handle any unknown EC by injecting an UNDEFINED
> exception into the guest, with a corresponding (ratelimited) warning in
> the host dmesg. We could later improve on this with with a new (opt-in)
> exit to the host userspace.
>
> Signed-off-by: Mark Rutland
> Cc: Christoffer Dall
> Cc: Dave Martin
> Cc: Marc Zyngier
> Cc: Suzuki K Poulose
> ---
> arch/arm64/kvm/handle_exit.c | 19 ---
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index 1bfe30d..fa1b18e 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -135,7 +135,19 @@ static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu,
> struct kvm_run *run)
> return ret;
> }
>
> +static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu, struct kvm_run *run)
> +{
> + u32 hsr = kvm_vcpu_get_hsr(vcpu);
> +
> + kvm_pr_unimpl("Unknown exception class: hsr: %#08x -- %s\n",
> + hsr, esr_get_class_string(hsr));
> +
> + kvm_inject_undefined(vcpu);
> + return 1;
> +}
> +
> static exit_handle_fn arm_exit_handlers[] = {
> + [0 ... ESR_ELx_EC_MAX] = kvm_handle_unknown_ec,
> [ESR_ELx_EC_WFx]= kvm_handle_wfx,
> [ESR_ELx_EC_CP15_32]= kvm_handle_cp15_32,
> [ESR_ELx_EC_CP15_64]= kvm_handle_cp15_64,
> @@ -162,13 +174,6 @@ static exit_handle_fn kvm_get_exit_handler(struct
> kvm_vcpu *vcpu)
> u32 hsr = kvm_vcpu_get_hsr(vcpu);
> u8 hsr_ec = ESR_ELx_EC(hsr);
>
> - if (hsr_ec >= ARRAY_SIZE(arm_exit_handlers) ||
> - !arm_exit_handlers[hsr_ec]) {
> - kvm_err("Unknown exception class: hsr: %#08x -- %s\n",
> - hsr, esr_get_class_string(hsr));
> - BUG();
> - }
> -
> return arm_exit_handlers[hsr_ec];
> }
>
> --
Reviewed-by: Christoffer Dall
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH 2/2] arm64/kvm: survive unknown traps from guests
On Mon, Feb 20, 2017 at 01:48:32PM +, Suzuki K Poulose wrote: > On 20/02/17 12:30, Mark Rutland wrote: > >The patch makes KVM handle any unknown EC by injecting an UNDEFINED > >exception into the guest, with a corresponding (ratelimited) warning in > >the host dmesg. We could later improve on this with with a new (opt-in) > >exit to the host userspace. > > If the unknown EC happens to be an asynchronous exception (allocated > from the second range), we are not sure if that was triggered by this > guest, or a different guest or even the hypervisor if we cannot really > isolate the exception(with/without the RAS extensions, i.e ESB). Sure; that is certainly a worry. > And I accept there may not be a perfect solution to the problem > either. May be we could explicitly mention about "unsure" exceptions, > so that it might help, people who may not really have the deep > knowledge about the exception code schemes. I guess we could, though I'm not sure how this is going to be helpful for those without an understanding of the EC values. We can only say it *may* be an asynchronous exception, so to understand the issue you need to understand the EC value. Thanks, Mark. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH 2/2] arm64/kvm: survive unknown traps from guests
On 20/02/17 12:30, Mark Rutland wrote: Currently we BUG() if we see an ESR_EL2.EC value we don't recognise. As configurable disables/enables are added to the architecture (controlled by RES1/RES0 bits respectively), with associated synchronous exceptions, it may be possible for a guest to trigger exceptions with classes that we don't recognise. While we can't service these exceptions in a manner useful to the guest, we can avoid bringing down the host. Per ARM DDI 0487A.k_iss10775, page D7-1937, EC values within the range 0x00 - 0x2c are reserved for future use with synchronous exceptions, and EC values within the range 0x2d - 0x3f may be used for either synchronous or asynchronous exceptions. The patch makes KVM handle any unknown EC by injecting an UNDEFINED exception into the guest, with a corresponding (ratelimited) warning in the host dmesg. We could later improve on this with with a new (opt-in) exit to the host userspace. If the unknown EC happens to be an asynchronous exception (allocated from the second range), we are not sure if that was triggered by this guest, or a different guest or even the hypervisor if we cannot really isolate the exception(with/without the RAS extensions, i.e ESB). And I accept there may not be a perfect solution to the problem either. May be we could explicitly mention about "unsure" exceptions, so that it might help, people who may not really have the deep knowledge about the exception code schemes. Suzuki ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
