Received: by 10.223.185.116 with SMTP id b49csp3683485wrg; Mon, 26 Feb 2018 04:22:27 -0800 (PST) X-Google-Smtp-Source: AH8x225b2yoEQu141ijkvlslZoX+qBx9fRaAaqH3+M0q1crCHb+6AA8bvXA+0Zh9msCfPH/H2BrT X-Received: by 2002:a17:902:a50d:: with SMTP id s13-v6mr10562096plq.191.1519647747029; Mon, 26 Feb 2018 04:22:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519647746; cv=none; d=google.com; s=arc-20160816; b=GXRlqhhD/5Whd+6+oVOI8v/oSRQTh5S52J5hc1QRx/UyzWWz/4//VxB5EAnFwbkofD F9zEgBJemueE4FKSJYVrhqXMv2LapXgD1KC71o4u4vjTOWfRsVki9fQEqTAxct7AxAkj OBQczTeksDu85uqIX+ET7AjVyca0XoJu7athLyfwchGHB15Qk79t7MPqEmqhB6eK12k7 F7h6cq2QaeAyIY2/XGTtBAJ7iONyTRaiq/nGld4mG40RUjHgzG34PX8Ql45oxiv8hpXM d7AGflcWrZnE8lU/1OT1TbAIlYcahd1pRust1AM0oz4/cicLKpPwcm+KbZLRnUIwhDGD 2hJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=j4ELRDmVmlEhPAl2zR+t2fO+VNRJOBVLHyJ8yc77Dak=; b=vCecMBf3p3+ZOO82Sdsn+SMhSS8IPVv3sAJlcuIxl12lR+QZ7afGwWQA/gyQ4JFz84 DC8AC2DxH2qMvEM7N8T2Ok3ClbpqpoPrOl+e0adDTORXOnqqYD8xuSRbZja35UBC5jHF 4HPHXBOWee7mkuLmzuivbsFjbN21l7A5e6dWDWEb23XSidjjAB4cp3/x0lpQzFh1E+sR Fap3a1OT2YP2fSvNUiaF4IJ8/PQnp5opIGMlhxiwV/y1DkypXICeQ/UON5+9PETiXVNh qe9akiSXB1FzKfxePCch5V5q4N+l5a22eEd+E2uMbGQ9XV9tWzhHbMjbN1j1R2H+1o80 s+Nw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s195si5508208pgc.39.2018.02.26.04.22.12; Mon, 26 Feb 2018 04:22:26 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752501AbeBZMVY (ORCPT + 99 others); Mon, 26 Feb 2018 07:21:24 -0500 Received: from mail.skyhub.de ([5.9.137.197]:54618 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752383AbeBZMVS (ORCPT ); Mon, 26 Feb 2018 07:21:18 -0500 X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de Received: from mail.skyhub.de ([127.0.0.1]) by localhost (blast.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vsjY0kJMY3Ri; Mon, 26 Feb 2018 13:21:17 +0100 (CET) Received: from pd.tnic (p200300EC2BCE210020411134B639594E.dip0.t-ipconnect.de [IPv6:2003:ec:2bce:2100:2041:1134:b639:594e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 1314F1EC0991; Mon, 26 Feb 2018 13:21:17 +0100 (CET) Date: Mon, 26 Feb 2018 13:20:58 +0100 From: Borislav Petkov To: Paolo Bonzini Cc: Wanpeng Li , LKML , kvm , Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [PATCH] KVM: X86: Allow userspace to define the microcode version Message-ID: <20180226122058.GF4377@pd.tnic> References: <1519629838-4898-1-git-send-email-wanpengli@tencent.com> <20180226094148.GA15539@pd.tnic> <20180226104921.GA4377@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 26, 2018 at 12:47:27PM +0100, Paolo Bonzini wrote: > It's actually 0x100000000. Even more wrong. Revision ID is bits [31:0]. > Actually I think this patch makes sense, since some errata actually can > be worked around in the guest in the same way as the host. However, it > should also be tied to the recently introduced mechanism to read MSR > contents from the host. So if we decide to do microcode revisions in the guest, we should consider the fact that microcode revisions need to be handled the same way as CPUID bits: a revision number means something on baremetal and implies a certain functionality, just like a set CPUID bit does. So we either have that same functionality in the guest or we don't talk about revisions at all. Because if we end up lying by coming up with revision numbers, all hell will break loose in the guest. IMO, of course. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.