From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH 7/24] consolidate msr.h Date: Tue, 20 Nov 2007 06:51:13 +0100 Message-ID: <20071120055113.GC20436@elte.hu> References: <11946337851964-git-send-email-gcosta@redhat.com> <11946337933104-git-send-email-gcosta@redhat.com> <11946337991750-git-send-email-gcosta@redhat.com> <11946338053158-git-send-email-gcosta@redhat.com> <11946338103068-git-send-email-gcosta@redhat.com> <1194633815833-git-send-email-gcosta@redhat.com> <11946338212915-git-send-email-gcosta@redhat.com> <11946338263902-git-send-email-gcosta@redhat.com> <20071119222151.GA11178@wavehammer.waldi.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: lguest-mnsaURCQ41sdnm+yROfE0A@public.gmane.org, jun.nakajima-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Bastian Blank , anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, Glauber de Oliveira Costa , virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org, ak-l3A5Bk7waGM@public.gmane.org To: Steven Rostedt Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: lguest-bounces+glkvl-lguest=m.gmane.org-mnsaURCQ41sdnm+yROfE0A@public.gmane.org Errors-To: lguest-bounces+glkvl-lguest=m.gmane.org-mnsaURCQ41sdnm+yROfE0A@public.gmane.org List-Id: kvm.vger.kernel.org * Steven Rostedt wrote: > > On Fri, Nov 09, 2007 at 04:42:48PM -0200, Glauber de Oliveira Costa wrote: > > > - wrmsrl(MSR_CSTAR, ia32_cstar_target); > > > + wrmsrl(MSR_CSTAR, (u64)ia32_cstar_target); > > > > Hmm, why do you add explicit casts? The compiler should convert that > > correctly on its own. > > > > > +static inline void wrmsrl(unsigned int msr, unsigned long long val) > > > > Hmm, long long is 64 bit on all x86, but why not use explicit u64 to > > show that? > > (quick reply) > > With PVOPS on it gives compiler warnings without that explict cast. > Without looking at the code, IIRC with non-PVOPS it is a macro > directly into asm, so it didn't matter what the cast was. But with > PVOPS as a function, it gave compiler warnings. > > Take it out and try compiling it for both i386 and x86_64. One of them > gave warnings. But maybe it's not a problem now. i dont think there's ever any true need (and good cause) to force integer type casts like that at the callee site. Ingo