From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6Tf9-0003Im-6O for qemu-devel@nongnu.org; Tue, 28 Aug 2012 17:49:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T6Tf7-0001er-QA for qemu-devel@nongnu.org; Tue, 28 Aug 2012 17:49:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22048) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6Tf7-0001el-Hc for qemu-devel@nongnu.org; Tue, 28 Aug 2012 17:49:29 -0400 Date: Wed, 29 Aug 2012 00:50:39 +0300 From: "Michael S. Tsirkin" Message-ID: <20120828215038.GF5817@redhat.com> References: <246329d9a275f3735aeaeab9326b1527330fe13a.1346069810.git.mst@redhat.com> <20120827190636.GC13049@redhat.com> <20120827192452.GE13049@redhat.com> <20120828154626.GD2903@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCHv2 3/4] cpuid: disable pv eoi for 1.1 and older compat types List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: gleb@redhat.com, kvm@vger.kernel.org, mtosatti@redhat.com, qemu-devel@nongnu.org, Blue Swirl , Jan Kiszka , avi@redhat.com, Anthony Liguori On Tue, Aug 28, 2012 at 09:02:05PM +0400, malc wrote: > On Tue, 28 Aug 2012, Michael S. Tsirkin wrote: > > > On Mon, Aug 27, 2012 at 07:40:56PM +0000, Blue Swirl wrote: > > > On Mon, Aug 27, 2012 at 7:24 PM, Michael S. Tsirkin wrote: > > > > On Mon, Aug 27, 2012 at 07:12:27PM +0000, Blue Swirl wrote: > > > >> On Mon, Aug 27, 2012 at 7:06 PM, Michael S. Tsirkin wrote: > > > >> > On Mon, Aug 27, 2012 at 06:58:29PM +0000, Blue Swirl wrote: > > > >> >> On Mon, Aug 27, 2012 at 12:20 PM, Michael S. Tsirkin wrote: > > > >> >> > In preparation for adding PV EOI support, disable PV EOI by default for > > > >> >> > 1.1 and older machine types, to avoid CPUID changing during migration. > > > >> >> > > > > >> >> > PV EOI can still be enabled/disabled by specifying it explicitly. > > > >> >> > Enable for 1.1 > > > >> >> > -M pc-1.1 -cpu kvm64,+kvm_pv_eoi > > > >> >> > Disable for 1.2 > > > >> >> > -M pc-1.2 -cpu kvm64,-kvm_pv_eoi > > > >> >> > > > > >> >> > Signed-off-by: Michael S. Tsirkin > > > >> >> > --- > > > >> >> > hw/Makefile.objs | 2 +- > > > >> >> > hw/cpu_flags.c | 32 ++++++++++++++++++++++++++++++++ > > > >> >> > hw/cpu_flags.h | 9 +++++++++ > > > >> >> > hw/pc_piix.c | 2 ++ > > [..snip..] > > > > > > > No leading underscores. They are not used in QEMU. > > > > They are *widely* used in QEMU to mark internal > > stuff. E.g. parameters in many macros. > > > > ISO/IEC 9899:TC3 7.1.3#1 > > - All identifiers that begin with an underscore and either an > uppercase letter or another underscore are always reserved for any use. > > IOW no __ or _[A-Z] at all. > > - All identifiers that begin with an underscore are always reserved > for use as identifiers with file scope in both the ordinary and tag > name spaces. > > IOW _ as the name of an argument to a macro is (probably) okay. > > > In reality __ is also widely used. I'm still mulling > > removing 2.4 from HACKING - it appears too draconian, > > the chances of a conflict with preprocessor are remote > > and if it triggers, it's trivial to catch. > > We also have lots of existing code violating this rule. > > > > And the rule about _t suffix is just silly. > > http://pubs.opengroup.org/onlinepubs/7908799/xns/namespace.html > > [..snip..] It's still silly :) > -- > mailto:av1474@comtv.ru