Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754780AbeAMGVO (ORCPT + 1 other); Sat, 13 Jan 2018 01:21:14 -0500 Received: from mail.kernel.org ([198.145.29.99]:34446 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754710AbeAMGVN (ORCPT ); Sat, 13 Jan 2018 01:21:13 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9723E2177F 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: ACJfBovKOPh49pSoAN1p/s5P9S5oSDO9G0CEovkm7lh9aNkAbUbuU26f7MTvHFDA8dbg+85hVDBqcSMAT+mR3vqcPbE= MIME-Version: 1.0 In-Reply-To: <917cf067-c986-a459-ea87-7b7724c3c2d6@intel.com> 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> <917cf067-c986-a459-ea87-7b7724c3c2d6@intel.com> From: Andy Lutomirski Date: Fri, 12 Jan 2018 22:20:51 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/5] x86/ibrs: Introduce native_rdmsrl, and native_wrmsrl To: Dave Hansen Cc: "Raj, Ashok" , Andy Lutomirski , LKML , Thomas Gleixner , Tim Chen , Linus Torvalds , Greg KH , 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 9:03 PM, Dave Hansen wrote: > On 01/11/2018 07: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. > > We were also worried about the indirect calls that are part of the > paravirt interfaces when retpolines are not in place. > How could those possibly be any worse than any other indirect call in the kernel?