qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 4/5] kvmppc: Translate eaddr for fsl_booke mmu


From: Hollis Blanchard
Subject: [Qemu-devel] Re: [PATCH 4/5] kvmppc: Translate eaddr for fsl_booke mmu
Date: Wed, 19 Aug 2009 15:51:24 -0700

On Tue, 2009-08-04 at 17:36 +0800, Liu Yu wrote:
> Signed-off-by: Liu Yu <address@hidden>
> ---
>  target-ppc/helper.c |   17 +++++++++++++++--
>  1 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/target-ppc/helper.c b/target-ppc/helper.c
> index 6eca2e5..07e56a4 100644
> --- a/target-ppc/helper.c
> +++ b/target-ppc/helper.c
> @@ -22,6 +22,7 @@
>  #include <string.h>
>  #include <inttypes.h>
>  #include <signal.h>
> +#include <linux/kvm.h>
> 
>  #include "cpu.h"
>  #include "exec-all.h"
> @@ -1325,8 +1326,20 @@ static always_inline int check_physical (CPUState 
> *env, mmu_ctx_t *ctx,
>          cpu_abort(env, "MPC8xx MMU model is not implemented\n");
>          break;
>      case POWERPC_MMU_BOOKE_FSL:
> -        /* XXX: TODO */
> -        cpu_abort(env, "BookE FSL MMU model not implemented\n");
> +        if (kvm_enabled()) {
> +            struct kvm_translation tr;
> +
> +            /* For now we only debug guest kernel */
> +            tr.linear_address = eaddr;
> +            ret = kvm_vcpu_ioctl(env, KVM_TRANSLATE, &tr);
> +            if (ret < 0)
> +                return ret;
> +
> +            ctx->raddr = tr.physical_address;
> +        } else {
> +            /* XXX: TODO */
> +            cpu_abort(env, "BookE FSL MMU model not implemented\n");
> +        }
>          break;
>      default:
>          cpu_abort(env, "Unknown or invalid MMU model\n");

One objection: the comment is a little obscure. I think what you're
really saying is "in Linux guests, kernel addresses should always be
covered by TLB1, which means for those addresses we can expect this
ioctl to succeed." However, since you need to handle failures anyways, I
think you should remove the comment entirely.

Second, (and this isn't an objection but rather a question) do you have
any better ideas for struct kvm_translation? It only really makes sense
for x86. We don't need to stick with it.

-- 
Hollis Blanchard
IBM Linux Technology Center






reply via email to

[Prev in Thread] Current Thread [Next in Thread]