Re: [Qemu-devel] Question about the block linking limitation

[Max Filippov]

>> s->pc is updated each time a byte of code is fetched, when an instruction
>> is fully decoded s->pc points to the first byte of the next instruction. I 
>> see
>> that it only makes difference when a branching instruction ends exactly at
>> a page boundary. In this case (s->pc - 1) prevents from linking to the next
>> page, which seems to be its main purpose.
>
>  That makes things clear to me. So, one tb is allowed to span guest pages, but
> not the linking between tbs, right?
>
>  From the previous discussion [1][2], you said the reason behind the block
> linking constraint is, if the guest page which the second tb2 belongs to is
> changed (swapped out or task switching), then QEMU has no chance to stop tb2
> from execution. My question is, what makes tb2 execution invalid? The code of

Nothing besides its absence in the virtual address space.
That is, the real CPU would behave differently.

> tb2 (in the code cache) is still the same, although the guest page containing
> tb2 is gone. Is it because tb2 need something, like data, in the guest page?
>
>  Doesn't a tb spanning guest pages have above problem? I mean what if the
> guest page 2 is changed? In this case, the execution flow jump from tb.a to
> tb.b. It seems it may have the same problem as above to me.

I agree. I see that only i386 and m68k TBs may cross page boundary.
Maybe it is due to the fact that these CPUs can normally have instructions
crossing page boundary due to the variable opcode length.

My best guess is that QEMU behavior in such corner cases differs from
the real CPU behavior, e.g. there'd be no exception in the TB crossing
page boundary from the present to non-present page. I'll try to make a
small testcase to prove (or disprove) it.

>     ________
>    |        |
>    |  tb.a  |   guest page 1
>  --------------
>    |  tb.b  |   guest page 2 (replaced with another guest code)
>    |________|
>
>
> Any idea on that? Thanks!

-- 
Thanks.
-- Max