From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751187AbdLIHvd (ORCPT ); Sat, 9 Dec 2017 02:51:33 -0500 Received: from smtp-fw-9102.amazon.com ([207.171.184.29]:56496 "EHLO smtp-fw-9102.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751008AbdLIHv3 (ORCPT ); Sat, 9 Dec 2017 02:51:29 -0500 X-IronPort-AV: E=Sophos;i="5.45,381,1508803200"; d="scan'208";a="579146892" From: "Sironi, Filippo" To: Steve Rutherford CC: Paolo Bonzini , =?iso-8859-2?Q?Radim_Kr=E8m=E1=F8?= , KVM list , LKML Subject: Re: [PATCH 2/2] KVM: x86: Allow userspace to define what's the microcode version Thread-Topic: [PATCH 2/2] KVM: x86: Allow userspace to define what's the microcode version Thread-Index: AQHTZtVpIVnd2IPHOEWS92aoXsxI36MoIFcAgACqq4CAEexUgA== Date: Sat, 9 Dec 2017 07:51:22 +0000 Message-ID: <9F8D2D88-6ACC-444A-8538-8B231051C969@amazon.de> References: <1511714482-3273-1-git-send-email-sironi@amazon.de> <1511714482-3273-2-git-send-email-sironi@amazon.de> <510cf2fb-1d53-485f-bfd1-3d852378c866@redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.165.12] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <454FCB85D7489146B6F138649911ACC5@amazon.com> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id vB97pbZv013861 > On 27. Nov 2017, at 14:09, Steve Rutherford wrote: > > On Mon, Nov 27, 2017 at 3:58 AM, Paolo Bonzini wrote: >> On 26/11/2017 17:41, Filippo Sironi wrote: >>> ... that the guest should see. >>> Guest operating systems may check the microcode version to decide whether >>> to disable certain features that are known to be buggy up to certain >>> microcode versions. Address the issue by making the microcode version >>> that the guest should see settable. >>> The rationale for having userspace specifying the microcode version, rather >>> than having the kernel picking it, is to ensure consistency for live-migrated >>> instances; we don't want them to see a microcode version increase without a >>> reset. >>> >>> Signed-off-by: Filippo Sironi >>> --- >>> arch/x86/kvm/x86.c | 23 +++++++++++++++++++++++ >>> include/uapi/linux/kvm.h | 3 +++ >>> 2 files changed, 26 insertions(+) >>> >>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >>> index 925c3e29cad3..741588f27ebc 100644 >>> --- a/arch/x86/kvm/x86.c >>> +++ b/arch/x86/kvm/x86.c >>> @@ -4033,6 +4033,29 @@ long kvm_arch_vm_ioctl(struct file *filp, >>> } u; >>> >>> switch (ioctl) { >>> + case KVM_GET_MICROCODE_VERSION: { >>> + r = -EFAULT; >>> + if (copy_to_user(argp, >>> + &kvm->arch.microcode_version, >>> + sizeof(kvm->arch.microcode_version))) >>> + goto out; >>> + break; >>> + } >>> + case KVM_SET_MICROCODE_VERSION: { >>> + u32 microcode_version; >>> + >>> + r = -EFAULT; >>> + if (copy_from_user(µcode_version, >>> + argp, >>> + sizeof(microcode_version))) >>> + goto out; >>> + r = -EINVAL; >>> + if (!microcode_version) >>> + goto out; >>> + kvm->arch.microcode_version = microcode_version; >>> + r = 0; >>> + break; >>> + } >> >> Also, there's no need to define new ioctls, instead you can just place >> it in the vcpu and use KVM_GET_MSR/KVM_SET_MSR. I'd agree that's >> slightly less polished, but it matches what we do already for e.g. >> nested VMX model specific registers. And it spares you for writing the >> documentation that you didn't include in this patch. :) >> >> Paolo > > This feels good time to mention Peter Hornyack's old MSR KVM_EXIT > patches. With something like them, there would be no need to push this > into the kernel at all. That's one of the solution we discussed internally (at Amazon) but we didn't pursue yet given the need to release a quick fix for customers. I was thinking about implementing a mechanism to selectively go back to userspace to emulate MSRs; something that's not limited to KVM unhandled MSRs but that instead could even override KVM's handling. Filippo Amazon Development Center Germany GmbH Berlin - Dresden - Aachen main office: Krausenstr. 38, 10117 Berlin Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger Ust-ID: DE289237879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B