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 S1752502AbbIQPb0 (ORCPT <rfc822;w@1wt.eu>);
	Thu, 17 Sep 2015 11:31:26 -0400
Received: from mga01.intel.com ([192.55.52.88]:44761 "EHLO mga01.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752054AbbIQPbY (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 17 Sep 2015 11:31:24 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.17,547,1437462000"; 
   d="scan'208";a="807355776"
Subject: Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops
To: Paolo Bonzini <pbonzini@redhat.com>, Andy Lutomirski <luto@amacapital.net>,
        Ingo Molnar <mingo@kernel.org>
References: <cover.1442445946.git.luto@kernel.org>
 <20150917071920.GA14296@gmail.com>
 <CALCETrUQaHKjUak6QrF9-yJxdP0_=r+uSD=gi2a6FbYuQYmj8w@mail.gmail.com>
 <55FADBE6.9040008@linux.intel.com> <55FADC3D.70202@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>, X86 ML <x86@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>, KVM list <kvm@vger.kernel.org>,
        xen-devel <Xen-devel@lists.xen.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>,
        Andrew Morton <akpm@linux-foundation.org>,
        "H. Peter Anvin" <hpa@zytor.com>
From: Arjan van de Ven <arjan@linux.intel.com>
Message-ID: <55FADCBD.4070804@linux.intel.com>
Date: Thu, 17 Sep 2015 08:31:09 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <55FADC3D.70202@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 9/17/2015 8:29 AM, Paolo Bonzini wrote:
>
>
> On 17/09/2015 17:27, Arjan van de Ven wrote:
>>>
>>>> ( We should double check that rdmsr()/wrmsr() results are never left
>>>>     uninitialized, but are set to zero or so, for cases where the
>>>> return code is not
>>>>     checked. )
>>>
>>> It sure looks like native_read_msr_safe doesn't clear the output if
>>> the rdmsr fails.
>>
>> I'd suggest to return some poison not just 0...
>
> What about 0 + WARN?

why 0?

0xdeadbeef or any other pattern (even 0x3636363636) makes more sense (of course also WARN... but most folks don't read dmesg for WARNs)

(it's the same thing we do for list or slab poison stuff)