From patchwork Fri Jul 31 21:49:44 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Graf X-Patchwork-Id: 11695531 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 EBA2A138C for ; Fri, 31 Jul 2020 21:50:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D4738208E4 for ; Fri, 31 Jul 2020 21:50:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=amazon.com header.i=@amazon.com header.b="nB3wO3EG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727008AbgGaVuH (ORCPT ); Fri, 31 Jul 2020 17:50:07 -0400 Received: from smtp-fw-9101.amazon.com ([207.171.184.25]:19920 "EHLO smtp-fw-9101.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726881AbgGaVuG (ORCPT ); Fri, 31 Jul 2020 17:50:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1596232206; x=1627768206; h=from:to:cc:subject:date:message-id:mime-version; bh=TCl662mUkal176BNY6VRMbOf0sBUN6kp6uCGLE85bLE=; b=nB3wO3EGTr7NQEKhWraOY5/Cf8kz/DhvIoHKKyNf2yhObAeLpYYcqfAB Y6uR8R9W60XqpD2oHr5AnW8/hchfMKgVKbz8Q4HK3wtjUQJZLgmQfMTIm y2byfiU/hbWBvzftEaedGboAsmX55SASj5bHAy5PMyfxPIy6dHX12YrYV 8=; IronPort-SDR: oUPSmJGeLX2JoT+MfwiALEgEB86WPd23cJ0UzlfwclfAJLNTuYnXLpMRU7jlYkr6mN5h+jYvRa m5CMGeWGBxfQ== X-IronPort-AV: E=Sophos;i="5.75,419,1589241600"; d="scan'208";a="56451571" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1e-27fb8269.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 31 Jul 2020 21:50:03 +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-27fb8269.us-east-1.amazon.com (Postfix) with ESMTPS id D5063A2026; Fri, 31 Jul 2020 21:49:58 +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; Fri, 31 Jul 2020 21:49:58 +0000 Received: from u79c5a0a55de558.ant.amazon.com (10.43.160.100) by EX13D20UWC002.ant.amazon.com (10.43.162.163) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 31 Jul 2020 21:49:55 +0000 From: Alexander Graf To: Paolo Bonzini CC: Jonathan Corbet , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , "Joerg Roedel" , KarimAllah Raslan , Aaron Lewis , , , Subject: [PATCH v3 0/3] Allow user space to restrict and augment MSR emulation Date: Fri, 31 Jul 2020 23:49:44 +0200 Message-ID: <20200731214947.16885-1-graf@amazon.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 X-Originating-IP: [10.43.160.100] X-ClientProxiedBy: EX13D48UWA001.ant.amazon.com (10.43.163.52) 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. v1 -> v2: - s/ETRAP_TO_USER_SPACE/ENOENT/g - deflect all #GP injection events to user space, not just unknown MSRs. That was we can also deflect allowlist errors later - fix emulator case - new patch: KVM: x86: Introduce allow list for MSR emulation - new patch: KVM: selftests: Add test for user space MSR handling v2 -> v3: - return r if r == X86EMUL_IO_NEEDED - s/KVM_EXIT_RDMSR/KVM_EXIT_X86_RDMSR/g - s/KVM_EXIT_WRMSR/KVM_EXIT_X86_WRMSR/g - Use complete_userspace_io logic instead of reply field - Simplify trapping code - document flags for KVM_X86_ADD_MSR_ALLOWLIST - generalize exit path, always unlock when returning - s/KVM_CAP_ADD_MSR_ALLOWLIST/KVM_CAP_X86_MSR_ALLOWLIST/g - Add KVM_X86_CLEAR_MSR_ALLOWLIST - Add test to clear whitelist - Adjust to reply-less API - Fix asserts - Actually trap on MSR_IA32_POWER_CTL writes 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 | 153 +++++++++++ arch/x86/include/asm/kvm_host.h | 16 ++ arch/x86/include/uapi/asm/kvm.h | 15 ++ arch/x86/kvm/emulate.c | 18 +- arch/x86/kvm/x86.c | 241 +++++++++++++++++- 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 | 221 ++++++++++++++++ 9 files changed, 675 insertions(+), 7 deletions(-) create mode 100644 tools/testing/selftests/kvm/x86_64/user_msr_test.c