From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39E4CC388F7 for ; Tue, 10 Nov 2020 10:40:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C650A20795 for ; Tue, 10 Nov 2020 10:40:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ZravZIYZ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730651AbgKJKkn (ORCPT ); Tue, 10 Nov 2020 05:40:43 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:49274 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726900AbgKJKkm (ORCPT ); Tue, 10 Nov 2020 05:40:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605004840; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mFapeUoz9EK+CeReEbp81IVPN8G8zVDapgbISzQg6Vs=; b=ZravZIYZ904Xj210Gmu5ZbplPBdlSpO5rWG+ngA15PfevgyevZv0wZs4LJLGpyi8G/Rnhu 3IeEzh1F4VbD2kxfTQ3j/0FRltXscjCxKtMpm51gWLKd+foZj9mFu9/BMsB2EokUY7ihoF 3Z8sKcL+m9U204JeJkt4RQfNNO5v1pA= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-507-DxpXngPQN42gsEhcdRXRuA-1; Tue, 10 Nov 2020 05:40:38 -0500 X-MC-Unique: DxpXngPQN42gsEhcdRXRuA-1 Received: by mail-ej1-f70.google.com with SMTP id 27so4538788ejy.8 for ; Tue, 10 Nov 2020 02:40:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mFapeUoz9EK+CeReEbp81IVPN8G8zVDapgbISzQg6Vs=; b=tjaxCtdOhXN/ig9A3gdShxR+63ZjvjRJHrMFW0NZ/cUbLuR0g3AyU7C43hOAdLhByZ CNHgh4b3zfk5uxEKGnC4QW43eWRAhlUq/BIfJK34WZLILE+N6FUsj2Y/Q2nP6NAYvHag o5dTCnWSwCtOuG/tudmDPW0nmzEHq9QS7xuKGvG22rpNqjJ7CZOwcMwo/N6bL2ZQtHS4 jr2JjdccwlcXeM1wK+vTz/Utzp+innTFPTMR7MdG8k0UslRoBSpUahTJVOUXgi/+gJ6f WskPn1QzwDzrb8nb0t0MkF9VIDFwAWCgcyOM3tIe6+jeU0B0mdZAXfzX3Ft8+1k6Zb6W Fmww== X-Gm-Message-State: AOAM530fN3oBAIeIDudSAN1AwBPnLRjp2Wcs2Z7BqFx0cpNJzuJkkdLk VcbCyxGCSBE1vzyKPwNPWqjfRUxjCnKYHi/lg8X1xrmNsEIM7Bij3IpXAm7pbXa8jkKjl0eTwwE X6YHT8v9Us8ZFNSn97ietQWVH X-Received: by 2002:a17:906:1183:: with SMTP id n3mr19064863eja.188.1605004837137; Tue, 10 Nov 2020 02:40:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJwnjrd2VMYhvgmNsyYwtSr3fGttybQrjvuv3QVZvsz5l664w5dGcdQ9COwyU1SYrBNdF5vTUQ== X-Received: by 2002:a17:906:1183:: with SMTP id n3mr19064842eja.188.1605004836846; Tue, 10 Nov 2020 02:40:36 -0800 (PST) Received: from ?IPv6:2001:b07:6468:f312:c8dd:75d4:99ab:290a? ([2001:b07:6468:f312:c8dd:75d4:99ab:290a]) by smtp.gmail.com with ESMTPSA id m16sm8760572eja.58.2020.11.10.02.40.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Nov 2020 02:40:35 -0800 (PST) To: Borislav Petkov Cc: "Luck, Tony" , Jim Mattson , Qian Cai , "linux-kernel@vger.kernel.org" , "linux-tip-commits@vger.kernel.org" , x86 , "kvm@vger.kernel.org" References: <20201030190807.GA13884@agluck-desk2.amr.corp.intel.com> <160431588828.397.16468104725047768957.tip-bot2@tip-bot2> <3f863634cd75824907e8ccf8164548c2ef036f20.camel@redhat.com> <20201109232402.GA25492@agluck-desk2.amr.corp.intel.com> <20201110063151.GB7290@nazgul.tnic> <094c2395-b1b3-d908-657c-9bd4144e40ac@redhat.com> <20201110095615.GB9450@nazgul.tnic> From: Paolo Bonzini Subject: Re: [PATCH] x86/mce: Check for hypervisor before enabling additional error logging Message-ID: Date: Tue, 10 Nov 2020 11:40:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20201110095615.GB9450@nazgul.tnic> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/11/20 10:56, Borislav Petkov wrote: > On Tue, Nov 10, 2020 at 09:50:43AM +0100, Paolo Bonzini wrote: >> 1) ignore_msrs _cannot_ be on by default. You cannot know in advance that >> for all non-architectural MSRs it's okay for them to read as zero and eat >> writes. For some non-architectural MSR which never reads as zero on real >> hardware, who knows that there isn't some code using the contents of the MSR >> as a divisor, and causing a division by zero exception with ignore_msrs=1? > > So if you're emulating a certain type of hardware - say a certain CPU > model - then what are you saying? That you're emulating it but not > really all of it, just some bits? We try to emulate all that is described in the SDM as architectural, as long as we expose the corresponding CPUID leaves. However, f/m/s mean nothing when running virtualized. First, trying to derive any non-architectural property from the f/m/s is going to fail. Second, even the host can be anything as long as it's newer than the f/m/s that the VM reports (i.e. you can get a Sandy Bridge model and model name even if running on Skylake). Also, X86_FEATURE_HYPERVISOR might be clear even if running virtualized. (Thank you nVidia for using it to play market segmentation games). > Because this is what happens - the kernel checks that it runs on a > certain CPU type and this tells it that those MSRs are there. But then > comes virt and throws all assumptions out. > > So if it emulates a CPU model and the kernel tries to access those MSRs, > then the HV should ignore those MSR accesses if it doesn't know about > them. Why should the kernel change everytime some tool or virtualization > has shortcomings? See above: how can the hypervisor know a safe value for all MSRs, possibly including the undocumented ones? >> 3) because of (1) and (2), the solution is very simple. If the MSR is >> architectural, its absence is a KVM bug and we'll fix it in all stable >> versions. If the MSR is not architectural (and 17Fh isn't; not only it's >> not mentioned in the SDM, > > It is mentioned in the SDM. Oh right they moved the MSRs to a separate manual; found it now. Still, it's not architectural. > But maybe we should have a choice and maybe qemu/kvm should have a way > to ignore certain MSRs for certain CPU types, regardless of them being > architectural or not. If it makes sense to emulate certain non-architectural MSRs we can add them. Supporting the error control MSR wouldn't even be hard, but I'm not sure it makes sense: 1) that MSR has not been there on current processors for several years (and therefore Intel has clearly no intention of making architectural). For what we know, even current processors might not provide any of that extended information at all (and still the VM could present Sandy Bridge f/m/s). 2) it would only present extended error info if the host itself enables the bit, so one might question the wisdom of backporting that support this to stable kernels 3) It's unclear whether the guest would be able to use the extended error information at all (and in some cases the description in the manual is not even proper English: "allows the iMC to log first device error when corrected error is detected during normal read"?). 4) other hypervisors, including older distros, would likely have the same issue. Paolo