[Qemu-devel] env fields as TCG variables

[Qemu-devel] env fields as TCG variables

[Blue Swirl]

I wonder if the following bug scenario is possible.

Some of the env fields are accessible as TCG variables, like cpu_fsr
for Sparc floating point status register (%fsr), stored in the env
structure field env->fsr. When cpu_fsr is used in the generated code,
a host CPU register is allocated for this task. But env->fsr can be
modified directly in op_helper.c code. Isn't it then possible that the
register (which stores cpu_fsr) and the structure field in memory
(env->fsr) get out of sync?

If this is true, no code outside the generated code should ever modify
or even read env fields that are also available as TCG variables. Or
do I miss something?

Re: [Qemu-devel] env fields as TCG variables

[Edgar E. Iglesias]

On Tue, Sep 16, 2008 at 09:37:41PM +0300, Blue Swirl wrote:
> I wonder if the following bug scenario is possible.
> 
> Some of the env fields are accessible as TCG variables, like cpu_fsr
> for Sparc floating point status register (%fsr), stored in the env
> structure field env->fsr. When cpu_fsr is used in the generated code,
> a host CPU register is allocated for this task. But env->fsr can be
> modified directly in op_helper.c code. Isn't it then possible that the
> register (which stores cpu_fsr) and the structure field in memory
> (env->fsr) get out of sync?
> 
> If this is true, no code outside the generated code should ever modify
> or even read env fields that are also available as TCG variables. Or
> do I miss something?

Hello,

IIRC:
TCG writebacks before calling helpers. There used to be a bug with
qemu_ld/qemu_st like the one you described but it was fixed a long
time ago. I ran into that one with CRIS and avoided it for a while
by calling a dummy helper before load/stores.

Best regards

Re: [Qemu-devel] env fields as TCG variables

[Blue Swirl]

On 9/16/08, Edgar E. Iglesias <edgar.iglesias@axis.com> wrote:
> On Tue, Sep 16, 2008 at 09:37:41PM +0300, Blue Swirl wrote:
>  > I wonder if the following bug scenario is possible.
>  >
>  > Some of the env fields are accessible as TCG variables, like cpu_fsr
>  > for Sparc floating point status register (%fsr), stored in the env
>  > structure field env->fsr. When cpu_fsr is used in the generated code,
>  > a host CPU register is allocated for this task. But env->fsr can be
>  > modified directly in op_helper.c code. Isn't it then possible that the
>  > register (which stores cpu_fsr) and the structure field in memory
>  > (env->fsr) get out of sync?
>  >
>  > If this is true, no code outside the generated code should ever modify
>  > or even read env fields that are also available as TCG variables. Or
>  > do I miss something?
>
>
> Hello,
>
>  IIRC:
>  TCG writebacks before calling helpers. There used to be a bug with
>  qemu_ld/qemu_st like the one you described but it was fixed a long
>  time ago. I ran into that one with CRIS and avoided it for a while
>  by calling a dummy helper before load/stores.

OK, this solves the main part of the problem. But what about code
outside helpers, for example interrupt handling?

Re: [Qemu-devel] env fields as TCG variables

[Edgar E. Iglesias]

On Tue, Sep 16, 2008 at 10:31:01PM +0300, Blue Swirl wrote:
> On 9/16/08, Edgar E. Iglesias <edgar.iglesias@axis.com> wrote:
> > On Tue, Sep 16, 2008 at 09:37:41PM +0300, Blue Swirl wrote:
> >  > I wonder if the following bug scenario is possible.
> >  >
> >  > Some of the env fields are accessible as TCG variables, like cpu_fsr
> >  > for Sparc floating point status register (%fsr), stored in the env
> >  > structure field env->fsr. When cpu_fsr is used in the generated code,
> >  > a host CPU register is allocated for this task. But env->fsr can be
> >  > modified directly in op_helper.c code. Isn't it then possible that the
> >  > register (which stores cpu_fsr) and the structure field in memory
> >  > (env->fsr) get out of sync?
> >  >
> >  > If this is true, no code outside the generated code should ever modify
> >  > or even read env fields that are also available as TCG variables. Or
> >  > do I miss something?
> >
> >
> > Hello,
> >
> >  IIRC:
> >  TCG writebacks before calling helpers. There used to be a bug with
> >  qemu_ld/qemu_st like the one you described but it was fixed a long
> >  time ago. I ran into that one with CRIS and avoided it for a while
> >  by calling a dummy helper before load/stores.
> 
> OK, this solves the main part of the problem. But what about code
> outside helpers, for example interrupt handling?

Hi Again, Im not sure but if I understand correctly:
Interrupts are only taken between TB's and TCG writebacks globals at the end of TBs.
MMU faults work by writebacking globals before loads/stores.

Best regards

Re: [Qemu-devel] env fields as TCG variables

[Edgar E. Iglesias]

On Tue, Sep 16, 2008 at 09:41:56PM +0200, Edgar E. Iglesias wrote:
> On Tue, Sep 16, 2008 at 10:31:01PM +0300, Blue Swirl wrote:
> > On 9/16/08, Edgar E. Iglesias <edgar.iglesias@axis.com> wrote:
> > > On Tue, Sep 16, 2008 at 09:37:41PM +0300, Blue Swirl wrote:
> > >  > I wonder if the following bug scenario is possible.
> > >  >
> > >  > Some of the env fields are accessible as TCG variables, like cpu_fsr
> > >  > for Sparc floating point status register (%fsr), stored in the env
> > >  > structure field env->fsr. When cpu_fsr is used in the generated code,
> > >  > a host CPU register is allocated for this task. But env->fsr can be
> > >  > modified directly in op_helper.c code. Isn't it then possible that the
> > >  > register (which stores cpu_fsr) and the structure field in memory
> > >  > (env->fsr) get out of sync?
> > >  >
> > >  > If this is true, no code outside the generated code should ever modify
> > >  > or even read env fields that are also available as TCG variables. Or
> > >  > do I miss something?
> > >
> > >
> > > Hello,
> > >
> > >  IIRC:
> > >  TCG writebacks before calling helpers. There used to be a bug with
> > >  qemu_ld/qemu_st like the one you described but it was fixed a long
> > >  time ago. I ran into that one with CRIS and avoided it for a while
> > >  by calling a dummy helper before load/stores.
> > 
> > OK, this solves the main part of the problem. But what about code
> > outside helpers, for example interrupt handling?
> 
> Hi Again, Im not sure but if I understand correctly:
> Interrupts are only taken between TB's and TCG writebacks globals at the end of TBs.
> MMU faults work by writebacking globals before loads/stores.

Sorry that was only for D faults. I faults are only taken between TB's AFAICT, so those are OK.
Unless you do like CRIS and fetch across page boundaries within the same TB, but that's my bug :)

Best regards