qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] running out of Arm TB flags...


From: Alex Bennée
Subject: Re: [Qemu-devel] running out of Arm TB flags...
Date: Tue, 19 Mar 2019 15:54:10 +0000
User-agent: mu4e 1.1.0; emacs 26.1

Paolo Bonzini <address@hidden> writes:

> 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.

I think you still need a target_ulong for cs_base as some guests use it
for next_pc.

--
Alex Bennée



reply via email to

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