From patchwork Wed Feb 17 14:57:11 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxim Levitsky X-Patchwork-Id: 12091745 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17A8FC433DB for ; Wed, 17 Feb 2021 14:59:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BCC8B64E28 for ; Wed, 17 Feb 2021 14:59:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233651AbhBQO6z (ORCPT ); Wed, 17 Feb 2021 09:58:55 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:48003 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233493AbhBQO6x (ORCPT ); Wed, 17 Feb 2021 09:58:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613573846; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=/nfMcV36HhAE2XwGrmtu/12blU+jhydqABEFlCZsevo=; b=IvV108WgulYFq/yixRc49kNK1M9pLxX17eiYX+aCOg1r1ANWOeICEhjwY1Al7M2qBpHD+p XzRDSod9qwJ97ESJTQXC2eMBwhbACI0LgSiRfo7tO7MI5oQ/+zL9zkucqwJSe2G33AIFiT Iv1B/5lWaSOd03lR3J9iRCJTirpT+wk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-334-IRJ5lmrRPEe9OkOERklwfw-1; Wed, 17 Feb 2021 09:57:24 -0500 X-MC-Unique: IRJ5lmrRPEe9OkOERklwfw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C71E518A0837; Wed, 17 Feb 2021 14:57:22 +0000 (UTC) Received: from localhost.localdomain (unknown [10.35.206.33]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1797E10016F0; Wed, 17 Feb 2021 14:57:18 +0000 (UTC) From: Maxim Levitsky To: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Wanpeng Li , Borislav Petkov , Paolo Bonzini , Joerg Roedel , Jim Mattson , "H. Peter Anvin" , Sean Christopherson , x86@kernel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)), Thomas Gleixner , Vitaly Kuznetsov , Ingo Molnar , Maxim Levitsky Subject: [PATCH 0/7] KVM: random nested fixes Date: Wed, 17 Feb 2021 16:57:11 +0200 Message-Id: <20210217145718.1217358-1-mlevitsk@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org This is a set of mostly random fixes I have in my patch queue. - Patches 1,2 are minor tracing fixes from a patch series I sent some time ago which I don't want to get lost in the noise. - Patches 3,4 are for fixing a theoretical bug in VMX with ept=0, but also to allow to move nested_vmx_load_cr3 call a bit, to make sure that update to .inject_page_fault is not lost while entering a nested guest. - Patch 5 fixes running nested guests with npt=0 on host, which is sometimes useful for debug and such (especially nested). - Patch 6 fixes the (mostly theoretical) issue with PDPTR loading on VMX after nested migration. - Patch 7 is hopefully the correct fix to eliminate a L0 crash in some rare cases when a HyperV guest is migrated. This was tested with kvm_unit_tests on both VMX and SVM, both native and in a VM. Some tests fail on VMX, but I haven't observed new tests failing due to the changes. This patch series was also tested by doing my nested migration with: 1. npt/ept disabled on the host 2. npt/ept enabled on the host and disabled in the L1 3. npt/ept enabled on both. In case of npt/ept=0 on the host (both on Intel and AMD), the L2 eventually crashed but I strongly suspect a bug in shadow mmu, which I track separately. (see below for full explanation). This patch series is based on kvm/queue branch. Best regards, Maxim Levitsky PS: The shadow mmu bug which I spent most of this week on: In my testing I am not able to boot win10 (without nesting, HyperV or anything special) on either Intel nor AMD without two dimensional paging enabled (ept/npt). It always crashes in various ways during the boot. I found out (accidentally) that if I make KVM's shadow mmu not unsync last level shadow pages, it starts working. In addition to that, as I mentioned above this bug can happen on Linux as well, while stressing the shadow mmu with repeated migrations (and again with the same shadow unsync hack it just works). While running without two dimensional paging is very obsolete by now, a bug in shadow mmu is relevant to nesting, since it uses it as well. Maxim Levitsky (7): KVM: VMX: read idt_vectoring_info a bit earlier KVM: nSVM: move nested vmrun tracepoint to enter_svm_guest_mode KVM: x86: add .complete_mmu_init arch callback KVM: nVMX: move inject_page_fault tweak to .complete_mmu_init KVM: nSVM: fix running nested guests when npt=0 KVM: nVMX: don't load PDPTRS right after nested state set KVM: nSVM: call nested_svm_load_cr3 on nested state load arch/x86/include/asm/kvm-x86-ops.h | 1 + arch/x86/include/asm/kvm_host.h | 2 + arch/x86/kvm/mmu/mmu.c | 2 + arch/x86/kvm/svm/nested.c | 84 +++++++++++++++++++----------- arch/x86/kvm/svm/svm.c | 9 ++++ arch/x86/kvm/svm/svm.h | 1 + arch/x86/kvm/vmx/nested.c | 22 ++++---- arch/x86/kvm/vmx/nested.h | 1 + arch/x86/kvm/vmx/vmx.c | 13 ++++- 9 files changed, 92 insertions(+), 43 deletions(-)