qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 04/29] target-ppc: Copy and split gen_spr_7xx


From: Tom Musta
Subject: Re: [Qemu-devel] [PATCH v4 04/29] target-ppc: Copy and split gen_spr_7xx() for 970
Date: Tue, 03 Jun 2014 11:32:22 -0500
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 6/3/2014 4:27 AM, Alexey Kardashevskiy wrote:
> +static void gen_spr_book3s_pmu_user(CPUPPCState *env)
> +{
> +    spr_register(env, SPR_POWER_UMMCR0, "UMMCR0",
> +                 &spr_read_ureg, SPR_NOACCESS,
> +                 &spr_read_ureg, SPR_NOACCESS,
> +                 0x00000000);
> +    spr_register(env, SPR_POWER_UMMCR1, "UMMCR1",
> +                 &spr_read_ureg, SPR_NOACCESS,
> +                 &spr_read_ureg, SPR_NOACCESS,
> +                 0x00000000);
> +    spr_register(env, SPR_POWER_UPMC1, "UPMC1",
> +                 &spr_read_ureg, SPR_NOACCESS,
> +                 &spr_read_ureg, SPR_NOACCESS,
> +                 0x00000000);
> +    spr_register(env, SPR_POWER_UPMC2, "UPMC2",
> +                 &spr_read_ureg, SPR_NOACCESS,
> +                 &spr_read_ureg, SPR_NOACCESS,
> +                 0x00000000);
> +    spr_register(env, SPR_POWER_UPMC3, "UPMC3",
> +                 &spr_read_ureg, SPR_NOACCESS,
> +                 &spr_read_ureg, SPR_NOACCESS,
> +                 0x00000000);
> +    spr_register(env, SPR_POWER_UPMC4, "UPMC4",
> +                 &spr_read_ureg, SPR_NOACCESS,
> +                 &spr_read_ureg, SPR_NOACCESS,
> +                 0x00000000);
> +    spr_register(env, SPR_POWER_USIAR, "USIAR",
> +                 &spr_read_ureg, SPR_NOACCESS,
> +                 &spr_read_ureg, SPR_NOACCESS,
> +                 0x00000000);
> +}

The Uxxxx regs are writeable from supervisor state, aren't they?  (similar 
comment as UCTRL).

There is also this complicating factor in ISA 2.07 (P8) whereby the PMU Uxxxx 
SPRs are
readable/writeable based on the state of MMCR0[PMCC] (ick!).

I think either of these can be handled in follow up patches.  I am also not 
sure that I see a
compelling reason to model the MMCR0[PMCC] accessibility unless we actually 
start modeling the
PMU (hard).

Reviewed-by: Tom Musta <address@hidden>




reply via email to

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