Received: by 2002:a05:6359:322:b0:b3:69d0:12d8 with SMTP id ef34csp172890rwb; Wed, 10 Aug 2022 06:38:46 -0700 (PDT) X-Google-Smtp-Source: AA6agR7iHJY8kUQPtu49OrykskUUZ8zqrY2M5ef4/YStrt7ibFifRJn9GOQ3jLdVP7l8TGQwqAB7 X-Received: by 2002:a05:6402:4303:b0:43d:94f5:8081 with SMTP id m3-20020a056402430300b0043d94f58081mr26090620edc.288.1660138726004; Wed, 10 Aug 2022 06:38:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660138725; cv=none; d=google.com; s=arc-20160816; b=dZDXZiU1nS32wr0TbFtedGirO3D11chYDX9yVpLdvxHDgVXWJCue+DORzfPTmwV4d4 q2SgztpZRE2UhHgbl7kH6k49H3o/0KVaxlc7TyyRwhoUfD+6x7NjoCLNdUEUJU6uiA1L DXDTic8cd81ZTz+EID3xobTsmeB1h7OOotzfR5OwceAmkBUth5TvymWctUWzVI0n/L8n qkGE39bpfIJ35Bdmb5PfFnVsjAymUpca7DGF0g+7TvlSnb88+yZ8EI3ATgNSNxzbEcTL MicbXRekFOnQIw6NIZIPMqX9WhIVRQla0NzpKQQvFwmqXI9N/Qa4ajLfQ5eVMr1C1UHw d2mw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=k7c0qAQ5W21TXh6W0fKJeJBpzWI2+8i+EKNMQTdJqw4=; b=i//irQY9G84mHg6JgMzdzCIjgzPAjEjpxnlFrBErFo0NCL0iHg89c9mfUDRnFVjyD8 QwRHP73IMucCPCkZQ89RW1faxWb/Mj8Vvq2UTV0gta3f9ATe/JIY8TOvkZZ/CHk4f7wu 35C6aI0iYLgZ9agnxhW2FuNIrtm1/KGH9fZTb95Lm6zI8osgmRdKHJq67qY6me4xTHlF rrL8ZHccEMrMgq6FLbdts7kdmYXoj87pVmBeknQ6LM45fTxUtOViCPWcY7l1mLAYKY9W BNIPDtWJbqAwkx2S8bpCWIpoPbghyyEJat3bNH3punVWPmd/DzhSZ6Wc1tMDcirGNc2+ XErg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZvPgpIui; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sd35-20020a1709076e2300b00733002330edsi2937739ejc.342.2022.08.10.06.38.19; Wed, 10 Aug 2022 06:38:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZvPgpIui; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232627AbiHJNZq (ORCPT + 99 others); Wed, 10 Aug 2022 09:25:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232673AbiHJNZh (ORCPT ); Wed, 10 Aug 2022 09:25:37 -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 BDF592E68D for ; Wed, 10 Aug 2022 06:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660137935; 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: in-reply-to:in-reply-to:references:references; bh=k7c0qAQ5W21TXh6W0fKJeJBpzWI2+8i+EKNMQTdJqw4=; b=ZvPgpIuilkQJNeMvu6sBeB08JK7PELOEylKHGhvpGHQDqPf1fn9mAAdxmNpXCz6lDpmwkI vKNWjqolko74fmxdbOCRI5dSgFBcIqCxBQ9+kDWWkyZmvGOvI0KuicyEjvK63T+4SLxsl0 QpYgMA/s+2cblVMD4o2FxdDJHcysm2Q= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-458-k7fXLazxNpSYLQuksj390w-1; Wed, 10 Aug 2022 09:25:34 -0400 X-MC-Unique: k7fXLazxNpSYLQuksj390w-1 Received: by mail-qv1-f69.google.com with SMTP id ea7-20020ad458a7000000b00476b8d9bfdcso7766074qvb.18 for ; Wed, 10 Aug 2022 06:25:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc; bh=k7c0qAQ5W21TXh6W0fKJeJBpzWI2+8i+EKNMQTdJqw4=; b=LEW3d3Bikhh2174WIfxwHc+JjPI94T4Op/LfctFrVoc8CwCFhowahaR5eDbG25owor mGCVfI2oSIGJy+hifvFmCJrFnBbnxCsCfT8zZAxg2RsIyFYkIRmaIZYtHkb0B1yDymXi SVgdFgujbzX5rK8hP8iqV8jhwnT0pwLS7ODl73ayZZGE5WNpLWLhaNIg7UE6zRpUvaHc WAbDcyohiJLViFOf9mTfjgfomUlgOx5q2pN7ITY0pAU63oS0g5gNi0W1MO0PEBc5LiaY u4L/NUcVtFqZb1MokKmJP9qbW/zaWp4NViBqZ5uEhdsEA+A+99eLvuB+oLKBsNEfiDkz F07g== X-Gm-Message-State: ACgBeo2cUqzZgqlzQDbpYQNdFBb3k8vyVGoGlsWaYKy6yVH2xIDaw2wV AFEnxfCl6WXl9FUtNZFGUItEVfVn7DmefWuetcYSIYxFJCJ4JNB9FkPOtSxynxM7BSY9HtjMuLg Fo1mEWCbaTlObqowDk7fUcAgC X-Received: by 2002:ac8:5786:0:b0:343:3051:170d with SMTP id v6-20020ac85786000000b003433051170dmr5914747qta.429.1660137934059; Wed, 10 Aug 2022 06:25:34 -0700 (PDT) X-Received: by 2002:ac8:5786:0:b0:343:3051:170d with SMTP id v6-20020ac85786000000b003433051170dmr5914712qta.429.1660137933780; Wed, 10 Aug 2022 06:25:33 -0700 (PDT) Received: from [10.35.4.238] (bzq-82-81-161-50.red.bezeqint.net. [82.81.161.50]) by smtp.gmail.com with ESMTPSA id t26-20020a37ea1a000000b006b58fce19dasm13172726qkj.20.2022.08.10.06.25.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Aug 2022 06:25:33 -0700 (PDT) Message-ID: <866df4004138ba18c6503266b61661a2ed8536c6.camel@redhat.com> Subject: Re: [PATCH v3 00/13] SMM emulation and interrupt shadow fixes From: Maxim Levitsky To: Thomas Lamprecht , kvm@vger.kernel.org Cc: Borislav Petkov , Dave Hansen , linux-kernel@vger.kernel.org, Wanpeng Li , Ingo Molnar , Sean Christopherson , x86@kernel.org, Jim Mattson , Kees Cook , Thomas Gleixner , "H. Peter Anvin" , Joerg Roedel , Vitaly Kuznetsov , Paolo Bonzini Date: Wed, 10 Aug 2022 16:25:29 +0300 In-Reply-To: <96e0749a-6036-c728-d224-b812caadcd1b@proxmox.com> References: <20220803155011.43721-1-mlevitsk@redhat.com> <96e0749a-6036-c728-d224-b812caadcd1b@proxmox.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-5.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2022-08-10 at 14:00 +0200, Thomas Lamprecht wrote: > On 03/08/2022 17:49, Maxim Levitsky wrote: > > This patch series is a result of long debug work to find out why > > sometimes guests with win11 secure boot > > were failing during boot. > > > > During writing a unit test I found another bug, turns out > > that on rsm emulation, if the rsm instruction was done in real > > or 32 bit mode, KVM would truncate the restored RIP to 32 bit. > > > > I also refactored the way we write SMRAM so it is easier > > now to understand what is going on. > > > > The main bug in this series which I fixed is that we > > allowed #SMI to happen during the STI interrupt shadow, > > and we did nothing to both reset it on #SMI handler > > entry and restore it on RSM. > > > > V3: addressed most of the review feedback from Sean (thanks!) > > > > Best regards, > >         Maxim Levitsky > > > > Maxim Levitsky (13): > >   bug: introduce ASSERT_STRUCT_OFFSET > >   KVM: x86: emulator: em_sysexit should update ctxt->mode > >   KVM: x86: emulator: introduce emulator_recalc_and_set_mode > >   KVM: x86: emulator: update the emulation mode after rsm > >   KVM: x86: emulator: update the emulation mode after CR0 write > >   KVM: x86: emulator/smm: number of GPRs in the SMRAM image depends on > >     the image format > >   KVM: x86: emulator/smm: add structs for KVM's smram layout > >   KVM: x86: emulator/smm: use smram structs in the common code > >   KVM: x86: emulator/smm: use smram struct for 32 bit smram load/restore > >   KVM: x86: emulator/smm: use smram struct for 64 bit smram load/restore > >   KVM: x86: SVM: use smram structs > >   KVM: x86: SVM: don't save SVM state to SMRAM when VM is not long mode > >     capable > >   KVM: x86: emulator/smm: preserve interrupt shadow in SMRAM > > > >  arch/x86/include/asm/kvm_host.h |  11 +- > >  arch/x86/kvm/emulate.c          | 305 +++++++++++++++++--------------- > >  arch/x86/kvm/kvm_emulate.h      | 223 ++++++++++++++++++++++- > >  arch/x86/kvm/svm/svm.c          |  30 ++-- > >  arch/x86/kvm/vmx/vmcs12.h       |   5 +- > >  arch/x86/kvm/vmx/vmx.c          |   4 +- > >  arch/x86/kvm/x86.c              | 175 +++++++++--------- > >  include/linux/build_bug.h       |   9 + > >  8 files changed, 497 insertions(+), 265 deletions(-) > > > > FWIW, we tested the v2 on 5.19 and backported it to 5.15 with minimal adaption > required (mostly unrelated context change) and now also updated that backport > to the v3 of this patch series. > > Our reproducer got fixed with either, but v3 now also avoids triggering logs like: > >  Jul 29 04:59:18 mits4 QEMU[2775]: kvm: Could not update PFLASH: Stale file handle >  Jul 29 04:59:18 mits4 QEMU[2775]: kvm: Could not update PFLASH: Stale file handle >  Jul 29 07:15:46 mits4 kernel: kvm: vcpu 1: requested 191999 ns lapic timer period limited to 200000 ns >  Jul 29 11:06:31 mits4 kernel: kvm: vcpu 1: requested 105786 ns lapic timer period limited to 200000 ns > > which happened earlier (not sure how deep that correlates with the v2 vs. v3, but > it stuck out, so mentioning for sake of completeness). This is likely just a coincidence because V3 should not contain any functional changes vs v2. (If I remember correctly) > > For the backport to 5.15 we skipped "KVM: x86: emulator/smm: number of GPRs in > the SMRAM image depends on the image format", as that constant was there yet and > the actual values stayed the same for our case FWICT and adapted to slight context > changes for the others. > > So, the approach seems to fix our issue and we are already rolling out a kernel > to users for testing and got positive feedback there too. > > With above in mind: > > Tested-by: Thomas Lamprecht Thank you very much for testing! > > It would be also great to see this backported to still supported upstream stable kernels > from 5.15 onwards, as there the TDP MMU got by default enabled, and that is at least > increasing the chance of our reproducer to trigger dramatically. Best regards, Maxim Levitsky > > thx & cheers > Thomas >