On Fri, Dec 09, 2011 at 07:08:43PM -0500, Xin Tong wrote:
> can you forward me the patch please. Peter. Also, as far as I
> understand, tb unlinking can only happen in 2 cases.
>
> 1. some other tbs being invalidated.
> 2. interrrupt pending
http://lists.gnu.org/archive/html/qemu-devel/2011-09/
On Tue, Dec 13, 2011 at 08:29:50PM -0500, Xin Tong wrote:
> QEMU performs a recursive unchaining on the current executing tb when
> a timer fires. This timer is set by setitimer in the qemu-timer.c.
You mean dynticks_start_timer?
> This is what I mean by "interrupt pend
QEMU performs a recursive unchaining on the current executing tb when
a timer fires. This timer is set by setitimer in the qemu-timer.c.
This is what I mean by "interrupt pending". Of course, there are
interrupts from emulated devices as well, but i do not know how that
is set up, i.e. how tcg_han
> 1. some other tbs being invalidated.
> 2. interrrupt pending
Could you point out "interrrupt pending" means where? I'd like to take a look,
thanks. :)
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-278
can you forward me the patch please. Peter. Also, as far as I
understand, tb unlinking can only happen in 2 cases.
1. some other tbs being invalidated.
2. interrrupt pending
Am I right ?
Thanks
Xin
On Fri, Dec 9, 2011 at 6:45 PM, Peter Maydell wrote:
> On 9 December 2011 18:44, Xin Tong wro
On 9 December 2011 18:44, Xin Tong wrote:
> Currently, QEMU unchains TBs if there is an interrupt pending. I would
> like to know whether there is any reason behind this ? (why not
> checking interrupt status in the beginning of every tb ?)
The theory is that it's faster overall to do a slightly
Currently, QEMU unchains TBs if there is an interrupt pending. I would
like to know whether there is any reason behind this ? (why not
checking interrupt status in the beginning of every tb ?)
Thanks
Xin
