qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC for-2.13 11/12] target/ppc: Remove unnecessary POW


From: Cédric Le Goater
Subject: Re: [Qemu-devel] [RFC for-2.13 11/12] target/ppc: Remove unnecessary POWERPC_MMU_V3 flag from mmu_model
Date: Wed, 28 Mar 2018 12:19:37 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 03/28/2018 10:47 AM, David Gibson wrote:
> On Wed, Mar 28, 2018 at 09:49:25AM +0200, Cédric Le Goater wrote:
>> On 03/28/2018 09:43 AM, Cédric Le Goater wrote:
>>> On 03/27/2018 06:37 AM, David Gibson wrote:
>>>> The only place we test this flag is in conjunction with
>>>> ppc64_use_proc_tbl().  That checks for the LPCR_UPRT bit, which we already
>>>> ensure can't be set except on a machine with a v3 MMU (i.e. POWER9).
>>>
>>> hmm, ok, but what will I use for the PowerNV hash MMU support then ? 
>>
>> That will be POWERPC_MMU_3_00.
> 
> You could check for that explicitly, or you could just check for
> presence of non-NULL hash64_opts.  The idea is that will always be the
> case for cpus capable of using the hash MMU.

ok. I will rebase when your patchset is merged.
 
> I'm also considering adding a similar radix_opts with radix specific
> details.  

yes. It looks a bit unbalanced now.

> POWER9 would have both, since it can support either mode.
> 
>> I didn't realize mmu_model was so 
>> crowded ..
> 
> It's not so that it's short of space.  It's more that the mix of enum
> like pieces and bitflag like pieces like bits makes it confusing to
> know whether it should be tested with simple equality or with &.  And
> if testing with equality which bits should be masked for a sensible
> comparison.
> 
> Additionally, I'd like to get options that are strictly related to the
> hash mmu out of the general structures.

which are ? vrma_slb, rmls ?

C. 



reply via email to

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