From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752516AbeBZMVY (ORCPT ); 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 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 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.