From patchwork Wed Jul 29 23:59:26 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Graf X-Patchwork-Id: 11691939 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id DD1F713B6 for ; Wed, 29 Jul 2020 23:59:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BF077207F5 for ; Wed, 29 Jul 2020 23:59:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=amazon.com header.i=@amazon.com header.b="Ra6kVtES" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728052AbgG2X7u (ORCPT ); Wed, 29 Jul 2020 19:59:50 -0400 Received: from smtp-fw-9102.amazon.com ([207.171.184.29]:8562 "EHLO smtp-fw-9102.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727087AbgG2X7t (ORCPT ); Wed, 29 Jul 2020 19:59:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1596067189; x=1627603189; h=from:to:cc:subject:date:message-id:mime-version; bh=BnIoflnIdc7ZyZiSo9RV0WJeZH5KULhyI7DfDJalzNI=; b=Ra6kVtESpLO9GPojeksrVnxR3DZQNpqJTUTA/PPbiR8CL5Lf76ih/7jN kcPWEqDt0/EGbWFXZZ1qWIGbFlDFup+Yt7cRax8oLqHT5U4lnxiVAVRbP gI3gCiaqNzWJtK/JEF8j2OnPacv65L+5Zb3v6l/T/RaEw235zPgr4ODu6 M=; IronPort-SDR: 3mDP/UKhfqQQDllXMLHoST5EQR2tSsGYoX9QG/BFDcReTHRLM80nOZKQkr7AwpTTAn59Yegu6s uVkpBuqFlt/Q== X-IronPort-AV: E=Sophos;i="5.75,412,1589241600"; d="scan'208";a="64109951" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1e-17c49630.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 29 Jul 2020 23:59:44 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1e-17c49630.us-east-1.amazon.com (Postfix) with ESMTPS id C0D07A247B; Wed, 29 Jul 2020 23:59:40 +0000 (UTC) Received: from EX13D20UWC002.ant.amazon.com (10.43.162.163) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 23:59:40 +0000 Received: from u79c5a0a55de558.ant.amazon.com (10.43.162.109) by EX13D20UWC002.ant.amazon.com (10.43.162.163) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 23:59:37 +0000 From: Alexander Graf To: Paolo Bonzini CC: Jonathan Corbet , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , "Joerg Roedel" , KarimAllah Raslan , , , Subject: [PATCH v2 0/3] Allow user space to restrict and augment MSR emulation Date: Thu, 30 Jul 2020 01:59:26 +0200 Message-ID: <20200729235929.379-1-graf@amazon.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 X-Originating-IP: [10.43.162.109] X-ClientProxiedBy: EX13D04UWA002.ant.amazon.com (10.43.160.31) To EX13D20UWC002.ant.amazon.com (10.43.162.163) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org While tying to add support for the MSR_CORE_THREAD_COUNT MSR in KVM, I realized that we were still in a world where user space has no control over what happens with MSR emulation in KVM. That is bad for multiple reasons. In my case, I wanted to emulate the MSR in user space, because it's a CPU specific register that does not exist on older CPUs and that really only contains informational data that is on the package level, so it's a natural fit for user space to provide it. However, it is also bad on a platform compatibility level. Currrently, KVM has no way to expose different MSRs based on the selected target CPU type. This patch set introduces a way for user space to indicate to KVM which MSRs should be handled in kernel space. With that, we can solve part of the platform compatibility story. Or at least we can not handle AMD specific MSRs on an Intel platform and vice versa. In addition, it introduces a way for user space to get into the loop when an MSR access would generate a #GP fault, such as when KVM finds an MSR that is not handled by the in-kernel MSR emulation or when the guest is trying to access reserved registers. In combination with the allow list, the user space trapping allows us to emulate arbitrary MSRs in user space, paving the way for target CPU specific MSR implementations from user space. Alexander Graf (3): KVM: x86: Deflect unknown MSR accesses to user space KVM: x86: Introduce allow list for MSR emulation KVM: selftests: Add test for user space MSR handling Documentation/virt/kvm/api.rst | 115 +++++++++ arch/x86/include/asm/kvm_host.h | 13 + arch/x86/include/uapi/asm/kvm.h | 15 ++ arch/x86/kvm/emulate.c | 18 +- arch/x86/kvm/x86.c | 234 +++++++++++++++++- include/trace/events/kvm.h | 2 +- include/uapi/linux/kvm.h | 15 ++ tools/testing/selftests/kvm/Makefile | 1 + .../selftests/kvm/x86_64/user_msr_test.c | 199 +++++++++++++++ 9 files changed, 605 insertions(+), 7 deletions(-) create mode 100644 tools/testing/selftests/kvm/x86_64/user_msr_test.c