On 16.10.2015 19:36, Sergey Fedorov wrote: > On 16.10.2015 17:08, Sergey Fedorov wrote: >> On 16.10.2015 04:14, Richard Henderson wrote: >>> On 10/16/2015 03:36 AM, Peter Maydell wrote: >>>> On 14 October 2015 at 22:02, Richard Henderson <r...@twiddle.net> wrote: >>>>> On 10/15/2015 06:34 AM, Peter Maydell wrote: >>>>>> This is still the same cryptic comment we have in the >>>>>> targets which do do this. Can we have something >>>>>> that is a bit more explanatory about what is going on and >>>>>> why we need to do this, please? >>>>> Suggestions? >>>> ...well, I don't entirely understand the problem it's >>>> fixing, which is why I'm asking for a better comment :-) >>> Heh. Fair enough. How about >>> >>> /* The address covered by the breakpoint must be included in >>> [tb->pc, tb->pc + tb->size) in order to for it to be >>> properly cleared -- thus we increment the PC here so that >>> the logic setting tb->size below does the right thing. */ >>> >>> There are two edge cases that cause the problem with clearing that >>> could be described, but I think that the comment becomes too bulky, as >>> well as confuses the situation for someone cutting-and-pasting the >>> logic to a new port. >> Maybe we could rather fix that condition in >> tb_invalidate_phys_page_range()? It seems weird that it can't handle a >> zero-sized TB. > I think extending "!(tb_end <= start || tb_start >= end)" condition to > "!(tb_end <= start || tb_start >= end) || tb_start == start" would work > fine. Thoughts? I could prepare a patch for that.
But there are at least two other places which doesn't seem to support a zero-sized TB: build_page_bitmap(), and tb_gen_code() when checking if a next page is needed. Best, Sergey
