Re: [Qemu-devel] Xtensa misuse of tb_invalidate_phys_page_range()?

[Max Filippov <jcmvbkbc@gmail.com>]

>>> void HELPER(wsr_ibreaka)(uint32_t i, uint32_t v)
>>> {
>>>     if (env->sregs[IBREAKENABLE]&  (1<<  i)&&  env->sregs[IBREAKA + i]
>>> != v) {
>>>         tb_invalidate_phys_page_range(
>>>                 env->sregs[IBREAKA + i], env->sregs[IBREAKA + i] + 1, 0);
>>>         tb_invalidate_phys_page_range(v, v + 1, 0);
>>>     }
>>>     env->sregs[IBREAKA + i] = v;
>>> }
>>>
>>> tb_invalidate_phys_page_range() expects a virtual address in user mode,
>>> and a ram_addr_t in system mode.  I'm guessing that v is a virtual address?
>>
>> Yes, it's a virtual address here, as well as in wsr_lbeg/wsr_lend helpers.
>> I made a test for it and it actually fails. I wonder how could it stay unnoticed
>> that long :()
>
> There are many silent breakages like that, don't worry.
>
>>> This needs to be fixed for system mode if so (and in any case - even if
>>> it's a physical address, it needs to be translated to a ram_addr_t).
>>
>> Sure. Will try to fix it, though it's completely unclear to me now
>> how to do it efficiently.
>
> Since I'm rewriting this area, don't worry about efficiency.  Let's get
> it correct and after the rewrite we can reexamine efficiency.
>
> I imagine you'll need something like breakpoint_invalidate().

The following RFC patch takes the obvious approach of sharing the breakpoint_invalidate
implementation to address this issue. But if we're talking about correctness it's not
100% correct, because guest TLB is independent of both instruction breakpoints and
zero overhead loops, and at the moment of TB invalidation relevant TLB mapping may not
exist.

Even if we managed to record physical addresses of TBs at the current IBREAKA/LEND, it's
not enough because we need to invalidate TBs both at the old and at the new IBREAKA/LEND
virtual addresses.

What do you think, do we need yet another address-to-TB map?

-- 
Thanks.
-- Max