Received: by 10.223.185.116 with SMTP id b49csp3597497wrg; Mon, 26 Feb 2018 02:50:40 -0800 (PST) X-Google-Smtp-Source: AH8x227BCF0OQ6Ld6NuXP2v4vr1YxNO1tTGHl+L5qMfWLUFn3dKHzLlFVQc9xbEuocZ4sAOHlLqY X-Received: by 2002:a17:902:b7c1:: with SMTP id v1-v6mr10272101plz.315.1519642239991; Mon, 26 Feb 2018 02:50:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519642239; cv=none; d=google.com; s=arc-20160816; b=wyUnj8/1hxaDlDH/TLqnX2r3UbxzKllF0IvijdQx0gMLb1YS/4ElYxkm61Hm2juAh0 sV0nBjnswTvx0sxdtOiF0h9IUBY6q2bKTBccD3odosCWiIvnk8rKwvKtUyY5jiKzLruH vrQXVsxMZyOv+440ZamvMqh4NvmthLwn00aznhmaUyvQ3Ju1+L4Qv+57HVE10mZaqvKW nqS+dekawPySN0zf5nOb5EcZaqOOGy4xdqIvxLSa8wjVe+9tt/ycihvqZqpylB5xJrJg f6RP7kiMsvuw/aX6KObYr5BjQpZrPCRWAi/+aqOCwjk+YUOeCmiYeD1ZQkCYcEr6v0Wy bLyQ== 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=5PUjwLDrpMYm6nLMF190Bl9x9cB6k8C9IDEUdcrYi0Y=; b=ssZ053F/3hGA1VeQajyv4Q5GACC2/vOVn7ZayHuu2kuJ7FvenSP+URM/8909j6OrRu 0pdXQ0RBj9rF29w/2I4DsW8+Jjt1vZp2SAxTeGX7Iab+1sOCFP/6yB06tzwcOvh//7ie OBLIy0lzLoc+Wr6iOC3yYcHqJKuTd4flue0Gija5qhpfE8VN7DVg6TgyXEgE6JsTtI9/ 6mzPtSoKh38HuiNxSXcNb7n+xikbaM60J6hswdfDOFfFzYlKtJP1GJlRJWNAuIt2rFVb MQuipvE4mTRwD5gkFGoaYIgkOl5VNiyVMhjly/D3n6+H3PbvhReT235ZJoGQwLThGWmf tXqA== 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 b10si5352351pge.563.2018.02.26.02.50.25; Mon, 26 Feb 2018 02:50:39 -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 S1752376AbeBZKtq (ORCPT + 99 others); Mon, 26 Feb 2018 05:49:46 -0500 Received: from mail.skyhub.de ([5.9.137.197]:50762 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751858AbeBZKto (ORCPT ); Mon, 26 Feb 2018 05:49:44 -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 5Ukyqb_r0sR1; Mon, 26 Feb 2018 11:49:42 +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 9014D1EC0960; Mon, 26 Feb 2018 11:49:42 +0100 (CET) Date: Mon, 26 Feb 2018 11:49:21 +0100 From: Borislav Petkov To: Wanpeng Li Cc: LKML , kvm , Paolo Bonzini , Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [PATCH] KVM: X86: Allow userspace to define the microcode version Message-ID: <20180226104921.GA4377@pd.tnic> References: <1519629838-4898-1-git-send-email-wanpengli@tencent.com> <20180226094148.GA15539@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 06:06:42PM +0800, Wanpeng Li wrote: > I think it is the host admin(e.g. cloud provider)'s responsibility to > set an expected microcode revision. + vcpu->arch.microcode_version = 0x1; That already looks pretty arbitrary and non-sensical to me. >In addition, the non-sensical value which is written by the guest will >not reflect to guest-visible microcode revision and just be ignored in >this implementation. Huh? How so? So a guest will have *two* microcode revisions - both of which are most likely wrong?! This whole thing sounds like the wrong approach to me. > Linux (among the others) has checks to make sure that certain features > aren't enabled on a certain family/model/stepping if the microcode version > isn't greater than or equal to a known good version. It sounds to me like the proper fix is to make the kernel *not* look at microcode revisions when running virtualized. The same way we're not loading microcode in a guest: if (native_cpuid_ecx(1) & BIT(31)) Letting userspace control the microcode revision number is revision number management SNAFU waiting to happen IMO. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.