Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754620AbeAMGUU (ORCPT + 1 other); Sat, 13 Jan 2018 01:20:20 -0500 Received: from mail.kernel.org ([198.145.29.99]:33998 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750732AbeAMGUT (ORCPT ); Sat, 13 Jan 2018 01:20:19 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1A1B62177C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org X-Google-Smtp-Source: ACJfBovQZjOx7VgVz+6Svho86fLlAwN0x3TYHf+pIyoh2cVg0bMzXKBVLCywPj3nAyhKxqpm0ehL5FMfx/GvWrxh7sk= MIME-Version: 1.0 In-Reply-To: <20180112030139.GA46095@otc-nc-03> References: <1515720739-43819-1-git-send-email-ashok.raj@intel.com> <1515720739-43819-2-git-send-email-ashok.raj@intel.com> <20180112015231.GA44418@otc-nc-03> <20180112030139.GA46095@otc-nc-03> From: Andy Lutomirski Date: Fri, 12 Jan 2018 22:19:57 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/5] x86/ibrs: Introduce native_rdmsrl, and native_wrmsrl To: "Raj, Ashok" Cc: Andy Lutomirski , LKML , Thomas Gleixner , Tim Chen , Linus Torvalds , Greg KH , Dave Hansen , Andrea Arcangeli , Andi Kleen , Arjan Van De Ven , David Woodhouse , Peter Zijlstra , Dan Williams , Paolo Bonzini , Jun Nakajima , Asit Mallick Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Thu, Jan 11, 2018 at 7:01 PM, Raj, Ashok wrote: > On Thu, Jan 11, 2018 at 06:20:13PM -0800, Andy Lutomirski wrote: >> On Thu, Jan 11, 2018 at 5:52 PM, Raj, Ashok wrote: >> >> >> >> What's wrong with native_read_msr()? >> > >> > Yes, i think i should have added to msr.h. The names didn't read as a >> > pair, one was native_read_msr, wrmsrl could be taken over when paravirt is >> > defined? >> >> Why do you need to override paravirt? > > The idea was since these MSR's are passed through we shouldn't need to > handle them any differently. Also its best to do this as soon as possible > and avoid longer paths to get this barrier to hardware. > It should end up with essentially the same instructions at runtime. I'm generally in favor of using the less weird code when it will work.