qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [PATCH 1/2] target-ppc: Add helpers for updating a CPU's


From: Thomas Huth
Subject: Re: [Qemu-ppc] [PATCH 1/2] target-ppc: Add helpers for updating a CPU's SDR1 and external HPT
Date: Fri, 4 Mar 2016 10:59:17 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 04.03.2016 06:35, David Gibson wrote:
> When a Power cpu with 64-bit hash MMU has it's hash page table (HPT)
> pointer updated by a write to the SDR1 register we need to update some
> derived variables.  Likewise, when the cpu is configured for an external
> HPT (one not in the guest memory space) some derived variables need to be
> updated.
> 
> Currently the logic for this is (partially) duplicated in ppc_store_sdr1()
> and in spapr_cpu_reset().  In future we're going to need it in some other
> places, so make some common helpers for this update.
> 
> In addition the new ppc_hash64_set_external_hpt() helper also updates
> SDR1 in KVM - it's not updated by the normal runtime KVM <-> qemu CPU
> synchronization.  In a sense this belongs logically in the
> ppc_hash64_set_sdr1() helper, but that is called from
> kvm_arch_get_registers() so can't itself call cpu_synchronize_state()
> without infinite recursion.  In practice this doesn't matter because
> the only other caller is TCG specific.
> 
> Currently there aren't situations where updating SDR1 at runtime in KVM
> matters, but there are going to be in future.
> 
> Signed-off-by: David Gibson <address@hidden>
> ---
>  hw/ppc/spapr.c          | 13 ++-----------
>  target-ppc/kvm.c        | 15 +++++++++++++++
>  target-ppc/kvm_ppc.h    |  6 ++++++
>  target-ppc/mmu-hash64.c | 42 ++++++++++++++++++++++++++++++++++++++++++
>  target-ppc/mmu-hash64.h |  6 ++++++
>  target-ppc/mmu_helper.c | 13 ++++++-------
>  6 files changed, 77 insertions(+), 18 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index e9d4abf..a88e3af 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1196,17 +1196,8 @@ static void spapr_cpu_reset(void *opaque)
>  
>      env->spr[SPR_HIOR] = 0;
>  
> -    env->external_htab = (uint8_t *)spapr->htab;
> -    env->htab_base = -1;
> -    /*
> -     * htab_mask is the mask used to normalize hash value to PTEG index.
> -     * htab_shift is log2 of hash table size.
> -     * We have 8 hpte per group, and each hpte is 16 bytes.
> -     * ie have 128 bytes per hpte entry.
> -     */
> -    env->htab_mask = (1ULL << (spapr->htab_shift - 7)) - 1;
> -    env->spr[SPR_SDR1] = (target_ulong)(uintptr_t)spapr->htab |
> -        (spapr->htab_shift - 18);
> +    ppc_hash64_set_external_hpt(cpu, spapr->htab, spapr->htab_shift,
> +                                &error_fatal);
>  }
>  
>  static void spapr_create_nvram(sPAPRMachineState *spapr)
> diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
> index d67c169..99b3231 100644
> --- a/target-ppc/kvm.c
> +++ b/target-ppc/kvm.c
> @@ -2537,3 +2537,18 @@ int kvmppc_enable_hwrng(void)
>  
>      return kvmppc_enable_hcall(kvm_state, H_RANDOM);
>  }
> +
> +int kvmppc_update_sdr1(PowerPCCPU *cpu)
> +{
> +    CPUState *cs = CPU(cpu);
> +
> +    if (!kvm_enabled()) {
> +        return 0; /* nothing to do */
> +    }

Since you're updating more than SDR1 below ... Could you maybe add a
"assert(cs->kvm_vcpu_dirty)" here, just to make sure that nobody
accidentally ever calls this function without synchronizing the
registers first?

> +    /* The normal KVM_PUT_RUNTIME_STATE doesn't include SDR1, which is
> +     * why we need an explicit update for it.  KVM_PUT_RESET_STATE is
> +     * overkill, but this is a pretty rare operation, so it's simpler
> +     * than writing a special purpose updater */
> +    return kvm_arch_put_registers(cs, KVM_PUT_RESET_STATE);
> +}

That indeed looks like a big overkill ... what about extracting the
block from kvm_arch_put_registers() which sets the the "struct
kvm_sregs" via KVM_SET_SREGS into a separate function, and then call
that function here instead?
kvm_arch_put_registers() is IMHO way too big anyway, so separating some
code into external functions there would improve readability there, too.

Apart from that, the patch looks right to me.

 Thomas




reply via email to

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