From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [Lguest] [PATCH 3/16] read/write_crX, clts and wbinvd for 64-bit paravirt Date: Thu, 01 Nov 2007 18:21:25 -0700 Message-ID: <472A7B95.2030001@goop.org> References: <472A0FBF.6040907@goop.org> <1193936113.29447.56.camel@bodhitayantram.eng.vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge , kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, ak-l3A5Bk7waGM@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Keir Fraser , lguest-mnsaURCQ41sdnm+yROfE0A@public.gmane.org, Glauber de Oliveira Costa , virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org To: Zachary Amsden Return-path: In-Reply-To: <1193936113.29447.56.camel-cxY/u30q8FloTgUnLF1by8fTvwmfpRNyZeezCHUQhQ4@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/