From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE035C433EF for ; Thu, 21 Apr 2022 05:13:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1384241AbiDUFPu (ORCPT ); Thu, 21 Apr 2022 01:15:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49020 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1384234AbiDUFPs (ORCPT ); Thu, 21 Apr 2022 01:15:48 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 19E01DED5 for ; Wed, 20 Apr 2022 22:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1650517978; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=gw2WgO3NdEKefNIzU7OyyGWhN8RKFPXQkhGeUbUxcYw=; b=H4gCGwZo+kQOBSN6IAilD8gW75BdBerAtTALOdZSJM88N/vzeKxK8y9gmZ6Z+X/kKAglT7 qMV29D+sfluHWxcP5kqv4q7JV5jpNAYb2bUR/zYmSouum8qWyO/77A1ALXUQa/8tVGS6AT /r6qgVveuGoBFDLWn6h1NPsTyPRqt/A= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-10-L9HPRdJxNBmr5i5MKpw9hg-1; Thu, 21 Apr 2022 01:12:53 -0400 X-MC-Unique: L9HPRdJxNBmr5i5MKpw9hg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D1D6880A0AD; Thu, 21 Apr 2022 05:12:51 +0000 (UTC) Received: from localhost.localdomain (unknown [10.40.194.231]) by smtp.corp.redhat.com (Postfix) with ESMTP id AEF55145B96B; Thu, 21 Apr 2022 05:12:45 +0000 (UTC) From: Maxim Levitsky To: kvm@vger.kernel.org Cc: Rodrigo Vivi , Paolo Bonzini , intel-gfx@lists.freedesktop.org, Joonas Lahtinen , Jani Nikula , Thomas Gleixner , linux-kernel@vger.kernel.org, Wanpeng Li , Jim Mattson , Tvrtko Ursulin , "H. Peter Anvin" , Vitaly Kuznetsov , Zhi Wang , Daniel Vetter , intel-gvt-dev@lists.freedesktop.org, dri-devel@lists.freedesktop.org, x86@kernel.org, David Airlie , Sean Christopherson , Ingo Molnar , Joerg Roedel , Dave Hansen , Borislav Petkov , Zhenyu Wang , Maxim Levitsky Subject: [RFC PATCH v2 00/10] RFCv2: nested AVIC Date: Thu, 21 Apr 2022 08:12:34 +0300 Message-Id: <20220421051244.187733-1-mlevitsk@redhat.com> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.85 on 10.11.54.7 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patch series implement everything that is needed to=0D use AMD's AVIC while a nested guest is running including=0D ability of the nested guest to use it, and brings feature=0D parity vs APICv.=0D =0D Compared to v1 of the series, there are lot of fixes,=0D and refactoring.=0D =0D This version still use unconditional read-only apic id,=0D which will be addressed in the next version.=0D =0D For the last patch, which allows to avoid cleaning is_running=0D bit in physid pages as long as it is possible, I measured=0D what would happen in a worst case:=0D =0D - A malicious guest runs with 2 vCPUs pinned,=0D its first vCPU pounds on ICR sending IPIs to the 2nd vCPU=0D =0D and 2nd vCPU scheduled out forever and not halted=0D (something that should not happen with Qemu though)=0D =0D - A normal guest with single vCPU is pinned to run=0D on the same CPU as the 2nd vCPU of the first guest.=0D =0D The normal guest continued to run, but was observed to run=0D about 40% slower.=0D =0D Therefore AVIC doorbel is strict by default but if the admin=0D policy is to pin guests and not allow them to share a physical=0D cpu, then strict doorbel can be set to false and that does=0D improves the nested (and not nested as well) AVIC perf futher.=0D =0D Suggestions, comments are welcome.=0D =0D Best regards,=0D Maxim Levitsky=0D =0D Maxim Levitsky (10):=0D KVM: x86: mmu: allow to enable write tracking externally=0D x86: KVMGT: use kvm_page_track_write_tracking_enable=0D KVM: x86: mmu: add gfn_in_memslot helper=0D KVM: x86: mmu: tweak fast path for emulation of access to nested NPT=0D pages=0D KVM: x86: lapic: don't allow to change APIC ID when apic acceleration=0D is enabled=0D KVM: x86: SVM: remove avic's broken code that updated APIC ID=0D KVM: x86: SVM: move avic state to separate struct=0D KVM: x86: rename .set_apic_access_page_addr to reload_apic_access_page=0D KVM: nSVM: implement support for nested AVIC=0D KVM: SVM: allow to avoid not needed updates to is_running=0D =0D arch/x86/include/asm/kvm-x86-ops.h | 2 +-=0D arch/x86/include/asm/kvm_host.h | 5 +-=0D arch/x86/include/asm/kvm_page_track.h | 1 +=0D arch/x86/kvm/Kconfig | 3 -=0D arch/x86/kvm/lapic.c | 28 +-=0D arch/x86/kvm/mmu.h | 8 +-=0D arch/x86/kvm/mmu/mmu.c | 21 +-=0D arch/x86/kvm/mmu/page_track.c | 10 +-=0D arch/x86/kvm/svm/avic.c | 949 ++++++++++++++++++++++++--=0D arch/x86/kvm/svm/nested.c | 131 +++-=0D arch/x86/kvm/svm/svm.c | 31 +-=0D arch/x86/kvm/svm/svm.h | 165 ++++-=0D arch/x86/kvm/trace.h | 140 +++-=0D arch/x86/kvm/vmx/vmx.c | 8 +-=0D arch/x86/kvm/x86.c | 17 +-=0D drivers/gpu/drm/i915/Kconfig | 1 -=0D drivers/gpu/drm/i915/gvt/kvmgt.c | 5 +=0D include/linux/kvm_host.h | 10 +-=0D 18 files changed, 1413 insertions(+), 122 deletions(-)=0D =0D -- =0D 2.26.3=0D =0D