qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v5 16/17] accel/tcg: Introduce TARGET_TB_PCREL


From: Alex Bennée
Subject: Re: [PATCH v5 16/17] accel/tcg: Introduce TARGET_TB_PCREL
Date: Fri, 30 Sep 2022 13:59:16 +0100
User-agent: mu4e 1.9.0; emacs 28.2.50

Peter Maydell <peter.maydell@linaro.org> writes:

> On Sun, 25 Sept 2022 at 12:15, Richard Henderson
> <richard.henderson@linaro.org> wrote:
>>
>> Prepare for targets to be able to produce TBs that can
>> run in more than one virtual context.
>
>> -/* Similarly, but for logs. */
>> +/*
>> + * Similarly, but for logs. In this case, when the virtual pc
>> + * is not available, use the physical address.
>> + */
>>  static inline target_ulong tb_pc_log(const TranslationBlock *tb)
>>  {
>> +#if TARGET_TB_PCREL
>> +    return tb->page_addr[0];
>> +#else
>>      return tb->pc;
>> +#endif
>>  }
>
> This is going to break previously working setups involving
> the "filter logging to a particular address range" and also
> anybody post-processing logfiles and expecting to see
> the virtual address in -d exec logging, I think.

To be honest I've never found -exec logging that useful for system
emulation (beyond check-tcg tests) because it just generates so much
data.

> For the exec logging, we surely must know the actual
> virtual PC at the point of TB execution -- we were
> previously just using tb->pc as a convenient architecture
> independent place to get that from, but should now do
> something else.
>
> For places where logging a virtual PC becomes meaningless,
> we should at least indicate whether we're logging a
> physaddr or a vaddr, because now depending on the config
> we might do either.

Yes we should extend the logging to say phys-pc or virt-pc 

> For the range-filter stuff, I'm not sure what to do.
> Alex, any ideas?
>
> (I see the -dfilter option documentation doesn't say
> whether it's intending to work on physical or virtual
> addresses...)

I have a feeling for system emulation phys-pc is the most natural but we
could extend the filter spec to be explicit.

>
> thanks
> -- PMM


-- 
Alex Bennée



reply via email to

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