On 17/11/14 09:27, wanghaibin wrote:
> It will be better to tell guest that there is something wrong with the instruction,
> than that there is something wrong with the vgic address area.
>
> Signed-off-by: wanghaibin <wanghaibin.wang@xxxxxxxxxx>
> ---
> virt/kvm/arm/vgic.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
> index d6a6c05..ec2192d 100644
> --- a/virt/kvm/arm/vgic.c
> +++ b/virt/kvm/arm/vgic.c
> @@ -1057,7 +1057,8 @@ bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
>
> /* We don't support ldrd / strd or ldm / stm to the emulated vgic */
> if (mmio->len > 4) {
> - kvm_inject_dabt(vcpu, mmio->phys_addr);
> + kvm_err("VGIC: Don't support the ldrd / strd or ldm / stm instructions \n");
> + kvm_inject_undefined(vcpu);
> return true;
> }
A few things:
- These instructions do exist, hence they cannot generate an UNDEF.
- It is not the instruction that is wrong. It is the access to the
memory region that is inapropriate.
- An Aarch64 ldr/str can generate a 8 byte access, and that's what we
want to trap here.
- Spamming the kernel log with something that is under direct control of
the guest is not exactly the brightest idea ever.
To be frank, the only thing that look vaguely wrong in that bit of code
is the comment.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
