From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754599AbbIQJDh (ORCPT ); Thu, 17 Sep 2015 05:03:37 -0400 Received: from casper.infradead.org ([85.118.1.10]:59539 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754412AbbIQJDd (ORCPT ); Thu, 17 Sep 2015 05:03:33 -0400 Date: Thu, 17 Sep 2015 10:58:07 +0200 From: Peter Zijlstra To: Andy Lutomirski Cc: x86@kernel.org, Paolo Bonzini , KVM list , Arjan van de Ven , xen-devel , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Message-ID: <20150917085807.GH3816@twins.programming.kicks-ass.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 16, 2015 at 04:33:11PM -0700, Andy Lutomirski wrote: > Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently > turns all rdmsr and wrmsr operations into the safe variants without > any checks that the operations actually succeed. > > This is IMO awful: it papers over bugs. In particular, KVM gueests > might be unwittingly depending on this behavior because > CONFIG_KVM_GUEST currently depends on CONFIG_PARAVIRT. I'm not > aware of any such problems, but applying this series would be a good > way to shake them out. > > Fix it so that the MSR operations work the same on CONFIG_PARAVIRT=n > and CONFIG_PARAVIRT=y as long as Xen isn't being used. The Xen > maintainers are welcome to make a similar change on top of this. > > Since there's plenty of time before the next merge window, I think > we should apply and fix anything that breaks. > > Doing this is probably a prerequisite to sanely decoupling > CONFIG_KVM_GUEST and CONFIG_PARAVIRT, which would probably make > Arjan and the rest of the Clear Containers people happy :) So I actually like this, although by Ingo's argument, its a tad risky. But the far greater problem I have with the whole virt thing is that you cannot use rdmsr_safe() to probe if an MSR exists at all because, as you told me, these virt thingies return 0 for all 'unknown' MSRs instead of faulting.