From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752264AbbIQPc6 (ORCPT <rfc822;w@1wt.eu>);
	Thu, 17 Sep 2015 11:32:58 -0400
Received: from smtp02.citrix.com ([66.165.176.63]:23562 "EHLO
	SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751384AbbIQPc5 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 17 Sep 2015 11:32:57 -0400
X-IronPort-AV: E=Sophos;i="5.17,547,1437436800"; 
   d="scan'208";a="304311943"
Message-ID: <55FADD25.6040909@citrix.com>
Date: Thu, 17 Sep 2015 16:32:53 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0
MIME-Version: 1.0
To: Borislav Petkov <bp@alien8.de>, Paolo Bonzini <pbonzini@redhat.com>
CC: Peter Zijlstra <a.p.zijlstra@chello.nl>, KVM list <kvm@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Linus Torvalds <torvalds@linux-foundation.org>, <x86@kernel.org>,
        <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        xen-devel <Xen-devel@lists.xen.org>, Andy Lutomirski <luto@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
        "Arjan van de Ven" <arjan@linux.intel.com>,
        Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt
 MSR ops
References: <cover.1442445946.git.luto@kernel.org>
	<20150917071920.GA14296@gmail.com>	<20150917093134.GC12316@nazgul.tnic>
 <55FAA66E.1070401@redhat.com> <20150917152709.GB17766@nazgul.tnic>
In-Reply-To: <20150917152709.GB17766@nazgul.tnic>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-DLP: MIA2
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 17/09/15 16:27, Borislav Petkov wrote:
> On Thu, Sep 17, 2015 at 01:39:26PM +0200, Paolo Bonzini wrote:
>> That's not a big deal, that's what *_safe is for.  The problem is that
>> there are definitely some cases where the *_safe version is not being used.
> I mean to do feature checks which assure you that those MSRs are
> there so you don't need the safe variants. And that is not always
> easy/possible.
>

There are plenty of non-architectural MSRs in use which don't have
feature bits.

Xen used to have problems booting when using the masking MSRs when
booting virtualised.  Nowadays it uses a cpu vendor check and _safe()
probe to detect support.

~Andrew