On Wed, Jan 25, 2012 at 01:58:10PM -0500, Xin Tong wrote:
> I am working on extending coremu (parallel version of qemu).
> Currently, the code cache in coremu is private, I am working towards
> to make it shared by all cores. I think the add_tb_jump may not be
> atomic.
If you're talking about [
On 25 January 2012 19:25, Xin Tong wrote:
> as I mentioned. In my current implementation of coremu, the code could
> be executed when it is modified. so the modifications need to be
> atomic. I think I need a scratch area in which the restore_cpu_state
> needs to be generated while leaving the alr
as I mentioned. In my current implementation of coremu, the code could
be executed when it is modified. so the modifications need to be
atomic. I think I need a scratch area in which the restore_cpu_state
needs to be generated while leaving the already generated code in
tact. would this solve the p
On 25 January 2012 19:10, Xin Tong wrote:
Peter Maydell wrote:
>> cpu_restore_state() calls gen_intermediate_code_pc() to
>> request a retranslation of the TB with extra info to allow
>> us to do a host-PC-to-guest-PC lookup
>> * Note that gen_intermediate_code_pc() overwrites the generated
>> co
you understood it correctly, I saw the code just after i sent out the email.
Thanks
Xin
On Wed, Jan 25, 2012 at 2:18 PM, James Greensky wrote:
> On Wed, Jan 25, 2012 at 11:10 AM, Xin Tong wrote:
>> cpu_restore_state() calls gen_intermediate_code_pc() to
>> request a retranslation of the TB wi
On Wed, Jan 25, 2012 at 11:10 AM, Xin Tong wrote:
> cpu_restore_state() calls gen_intermediate_code_pc() to
> request a retranslation of the TB with extra info to allow
> us to do a host-PC-to-guest-PC lookup
> * Note that gen_intermediate_code_pc() overwrites the generated
> code that already ex
cpu_restore_state() calls gen_intermediate_code_pc() to
request a retranslation of the TB with extra info to allow
us to do a host-PC-to-guest-PC lookup
* Note that gen_intermediate_code_pc() overwrites the generated
code that already exists in memory, and stops as soon as it
reaches the point of
I am working on extending coremu (parallel version of qemu).
Currently, the code cache in coremu is private, I am working towards
to make it shared by all cores. I think the add_tb_jump may not be
atomic.
Thanks
Xin
On Wed, Jan 25, 2012 at 11:22 AM, Peter Maydell
wrote:
> On 25 January 2012 15:
On 25 January 2012 15:55, Xin Tong wrote:
> The segfault is caused by jumping to the middle of an instruction. so
> i want to know which TB jumps here.
(a) Assuming it doesn't take too long to get there, you should
be able to get this information by turning on the debug log
via -d whatever. If it
> I have a bug, it segfaults when executing a translation blocks. when i
> disable block chaining, the bug disappears. However, with block
> chaining, i do not know which translation block jumps to the code
> which caused the segfault. I want to reserve a register and use it to
> record the last t
The segfault is caused by jumping to the middle of an instruction. so
i want to know which TB jumps here.
Thanks
Xin
On Wed, Jan 25, 2012 at 10:54 AM, Xin Tong wrote:
> I have a bug, it segfaults when executing a translation blocks. when i
> disable block chaining, the bug disappears. However
I have a bug, it segfaults when executing a translation blocks. when i
disable block chaining, the bug disappears. However, with block
chaining, i do not know which translation block jumps to the code
which caused the segfault. I want to reserve a register and use it to
record the last translation
On 25 January 2012 15:42, Xin Tong wrote:
> I tried to reserve a register in target-i386 with this code
>
> target-i386/translate.c tb_env = tcg_global_reg_new_ptr(TCG_AREG1, "env");
Why do you want to define a second global which holds the environment
variable? Just use TCG_AREG0 for that.
>
I tried to reserve a register in target-i386 with this code
target-i386/translate.ctb_env = tcg_global_reg_new_ptr(TCG_AREG1, "env");
i386/tcg-target.h #define TCG_AREG1 TCG_REG_R13
i386/tcg-target.c tcg_out_movi(s, TCG_TYPE_PTR, TCG_AREG1, args[0]);
But when i looked into t
On 25 January 2012 14:24, Xin Tong wrote:
> I am wondering how tcg reg alloc works. Specifically, how do i reserve
> a register only for one specific purpose. R14 on tcg i386 is reserved
> to point to the cpustate strcuture. it is assigned in the prologue,
> but what code makes sure that it is no
I am wondering how tcg reg alloc works. Specifically, how do i reserve
a register only for one specific purpose. R14 on tcg i386 is reserved
to point to the cpustate strcuture. it is assigned in the prologue,
but what code makes sure that it is not clobbered in the middle of a
TB ?
Thanks
Xin
16 matches
Mail list logo
