[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] running out of Arm TB flags...
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] running out of Arm TB flags... |
Date: |
Tue, 19 Mar 2019 16:06:15 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 |
On 19/03/19 11:18, Alex Bennée wrote:
>
> Richard Henderson <address@hidden> writes:
>
>> On 3/18/19 12:46 PM, Peter Maydell wrote:
>>> Hi; for the M-profile floating point work I'm going to need I think
>>> three new TB flags (to control whether to generate the code to do
>>> the various independent things the pseudocode ExecuteFPCheck() function
>>> does before executing any FP insn). Unfortunately we currently have
>>> only 2 unused bits in the arm TB flags word.
>>>
>>> I can see two possible ways to get the 3rd bit:
>>> (1) overload the meaning of an existing bit which I know isn't
>>> relevant to M-profile (eg the XSCALE_CPAR or VECLEN or VECSTRIDE bits)
>>> (2) start defining new bits in the currently-unused cs_base word
>>
>> Either works. But I'd probably reuse (or eliminate) XSCALE_CPAR first.
>> Afaik, xscale never had vfp, so CPAR could overlap FPEXC_EL?
>
> Agree, we should certainly be efficient with the base flags first (we
> already have overlap for AA32/64 states). I have no problem with using
> cs_base after that. We could bite the bullet and expand flags to 64 bits
> but I guess that will be a bit of a hit for 32 bit hosts.
>
> Given how many guests use the cs_base I wonder if it's time we came up
> with a better name for it: extra_tb_state, extra_state, moar_bits...
Or make the flags 64-bits by moving cs_base into the upper 32-bits of
flags... This way 32-bit hosts do not see any difference.
Paolo