Re: [Lguest] [PATCH 3/16] read/write_crX, clts and wbinvd for 64-bit paravirt

[Jeremy Fitzhardinge <jeremy@goop.org>]

Zachary Amsden wrote:
> I understood it as reordering was permitted, but no re-ordering across
> another volatile load, store, or asm was permitted.

It doesn't say that, so I wouldn't assume it.  Certainly we had problems
with the pda code; until I added the _proxy_pda dependency variable, the
only fix Andi could find was adding both "volatile" and a memory clobber.

>   And of course, as
> long as input and output constraints are written properly, the
> re-ordering should not be vulnerable to pathological movement causing
> the code to malfunction.
>   

Yes.  I think constraints are the only way to control ordering (even if
it's as heavy-handed as a memory clobber).  It would be nice if gcc had
a constraint which was only used for ordering, and never generated a
reference.  Then you could make up pseudo-variables in order to express
dependencies without having the risk that the compiler would generate
references.

> It seems that CPU state side effects which can't be expressed in C need
> special care - FPU is certainly one example.
>   

Not an immediate problem, fortunately.

> Also, memory clobber on a volatile asm should stop invalid movement
> across TLB flushes and other problems areas.

Yes.  Any asm which has global effects on how addresses are interpreted
(like tlbflush, reloading the pagetable base, changing modes, etc) needs
to have a memory clobber.

>   Even memory fences should
> have memory clobber in order to stop movement of loads and stores across
> the fence by the compiler.
>   

Pretty sure they do.  A normal compiler barrier is *just* a memory clobber.

    J