Hi ! I am trying to emulate mips on Qemu but during the kernel loading
process ,Qemu is sending a hardware interrupt which the kernel is not able
to handle and stucks in a loop while the actual hardware and simulator
don't send interrupt at that point.I want to know that which specific
function in
On 29 December 2011 00:48, Xin Tong wrote:
> That is my guess as well in the first place, but my QEMU is built with
> CONFIG_IOTHREAD set to 0.
Your QEMU is old -- iothread is now the only option (the config
option to use not-iothread has gone away).
> I am not 100% sure about how interrupts are
That is my guess as well in the first place, but my QEMU is built with
CONFIG_IOTHREAD set to 0.
I am not 100% sure about how interrupts are delivered in QEMU, my
guess is that some kind of timer devices will have to fire and qemu
might have installed a signal handler and the signal handler takes
On 28 December 2011 00:43, Xin Tong wrote:
> I modified QEMU to check for interrupt status at the end of every TB
> and ran it on SPECINT2000 benchmarks with QEMU 0.15.0. The performance
> is 70% of the unmodified one for some benchmarks on a x86_64 host. I
> agree that the extra load-test-branch-
Xin Tong writes:
> My main concern here is not how timely the interrupts can be handled,
> i am more interested in reducing the number of TB enters/exits due to
> interrupt. Returning to qemu mainloop requires saving and restoring
> register contexts which are expensive, what i am thinking is that
My main concern here is not how timely the interrupts can be handled,
i am more interested in reducing the number of TB enters/exits due to
interrupt. Returning to qemu mainloop requires saving and restoring
register contexts which are expensive, what i am thinking is that can
we check and handle i
On 12/28/2011 01:40 PM, Peter Maydell wrote:
> On 28 December 2011 10:42, Avi Kivity wrote:
> > It's possible to check for an interrupt before every instruction,
> > without any overhead:
> >
> > - when a signal arrives, check the instruction pointer. If it points
> > outside tcg code, set a flag
On 28 December 2011 10:42, Avi Kivity wrote:
> It's possible to check for an interrupt before every instruction,
> without any overhead:
>
> - when a signal arrives, check the instruction pointer. If it points
> outside tcg code, set a flag and return.
> - consult a table indexed by the instructio
On 12/28/2011 01:12 AM, Xin Tong wrote:
> QEMU does not exit and handle interrupt within translation blocks. it
> only exits after the translation block is finished. Assuming a
> translation block is very long, is it possible that QEMU could have
> exceeded the interrupt's "timing window" and yield
On Tue, Dec 27, 2011 at 6:10 PM, Peter Maydell wrote:
> On 28 December 2011 00:43, Xin Tong wrote:
>> Which version of QEMU did you do your test on, and what are the tests.
>
> It was whatever trunk qemu was a year or so ago, and the test was
> just "time to login prompt for ARM guest in system m
On 28 December 2011 00:43, Xin Tong wrote:
> Which version of QEMU did you do your test on, and what are the tests.
It was whatever trunk qemu was a year or so ago, and the test was
just "time to login prompt for ARM guest in system mode".
> I modified QEMU to check for interrupt status at the e
On Tue, Dec 27, 2011 at 4:36 PM, Peter Maydell wrote:
> On 27 December 2011 23:12, Xin Tong wrote:
>> The reason I ask is that I am searching for alternatives to QEMU
>> current way of handling interrupt (unlink translation blocks on
>> interrupt). However, an obvious approach - checking for inte
On 27 December 2011 23:12, Xin Tong wrote:
> The reason I ask is that I am searching for alternatives to QEMU
> current way of handling interrupt (unlink translation blocks on
> interrupt). However, an obvious approach - checking for interrupt in
> every basic block, seems to be too heavy ( too m
QEMU does not exit and handle interrupt within translation blocks. it
only exits after the translation block is finished. Assuming a
translation block is very long, is it possible that QEMU could have
exceeded the interrupt's "timing window" and yields unexpected
behavior.
The reason I ask is that
14 matches
Mail list logo
