Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp445769rwe; Thu, 25 Aug 2022 03:24:01 -0700 (PDT) X-Google-Smtp-Source: AA6agR4HkWMPNKNVZULLWmQQ8cd4Il0D4vqUbj376SnLUvc+eMEQUiAxuyFCwgZ/DJ/LgmDZ0FVN X-Received: by 2002:a17:902:ea0e:b0:16f:11bf:efe5 with SMTP id s14-20020a170902ea0e00b0016f11bfefe5mr3257150plg.57.1661423041532; Thu, 25 Aug 2022 03:24:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661423041; cv=none; d=google.com; s=arc-20160816; b=1JxQyg5PWz/SUURqQGOszNzHjbZ8QhxUm4LEe2dDYfFKby6wpxjT15etV68CkNov9T EZC7qgrfwaRZch38BgxlbJeQIc3bwPgRQGh2UCVH7CGt3+4CYSNWV1ei/eWR1ShTdJnF lsGtf/s44A29fYbhyMJhf2iXT896qt2q0NI/2m0fPpPdUaNqOl8rtS7uPx0OaJACBI9H 6qibdEuDc/4F1N8jZVm3iBJ4q/Oazx/bf51QXHh88/pJInhfLx7mPNKnEZBEsyeLMD9W aWNAdxwkRlYoK00FZcQP9QpJRx5W4xQoUdiHss66OhC+YYm6nwweW146Nm2ampmjphgt ABAw== 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=1On/L0KSwWBXLkoO7TYGZ7/I9PW/ScIQGzP4YPTC/Ns=; b=TfTuoVutM5i2A3dgAhE5lUElB1cMh5uFwsMwaXF3eg3C/G2HSHYm2LGiOb1nS161Y5 QHJJuNl0DVUb5qy2PKHmxkXBY5lgiY5JIKLfmZEozpbtG6gVVIUEpcpj6jStOCRHWL/i dlJiaxwH52/7xzrvysB0pvjbXEU569K/czzRVzcxj7lPeRxJaOtkFNgJqZOe76CJalrp rmTAKiWr/QIowhYMaimDehkB8g8yn+xg5AoH7vvp4tnadJZP3VT/0C1ME1jPp4QB8X2g G6i3lD+8ao7u3LNPlT8GTu1DXNStvKf6+jnFWN5troulUTossgEGGbuYH0P3QzYHqeTG o3Ng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=CX0Xyk0S; 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 k1-20020a170902ce0100b00170d34b95cdsi20356980plg.185.2022.08.25.03.23.49; Thu, 25 Aug 2022 03:24:01 -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=CX0Xyk0S; 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 S234328AbiHYKOB (ORCPT + 99 others); Thu, 25 Aug 2022 06:14:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58036 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241106AbiHYKNl (ORCPT ); Thu, 25 Aug 2022 06:13:41 -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 ESMTPS id 8CA27AC24B for ; Thu, 25 Aug 2022 03:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661422418; 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=1On/L0KSwWBXLkoO7TYGZ7/I9PW/ScIQGzP4YPTC/Ns=; b=CX0Xyk0SlotDShN+xCbZzCJiIxfS2DQz3VA0x3LTGAA/leYe8FGRxr0KNtqgue+nGkUCC1 wGO9gjyVwTFa5HW9O0KoVf7P4iW3t/PZs82/hsZfLmzymPNvfl19SRyJY9EiC3Grx+xDy9 jyBkvOxZHVnyaAPQULOlr6IQWN+5txw= 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-108-U_S0TIP6NOyWMqYrGjLNfA-1; Thu, 25 Aug 2022 06:13:35 -0400 X-MC-Unique: U_S0TIP6NOyWMqYrGjLNfA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9C82A101E989; Thu, 25 Aug 2022 10:13:34 +0000 (UTC) Received: from starship (unknown [10.40.194.96]) by smtp.corp.redhat.com (Postfix) with ESMTP id D208BC15BB3; Thu, 25 Aug 2022 10:13:29 +0000 (UTC) Message-ID: Subject: Re: [PATCH v3 13/13] KVM: x86: emulator/smm: preserve interrupt shadow in SMRAM From: Maxim Levitsky To: Sean Christopherson Cc: kvm@vger.kernel.org, Borislav Petkov , Dave Hansen , linux-kernel@vger.kernel.org, Wanpeng Li , Ingo Molnar , x86@kernel.org, Jim Mattson , Kees Cook , Thomas Gleixner , "H. Peter Anvin" , Joerg Roedel , Vitaly Kuznetsov , Paolo Bonzini Date: Thu, 25 Aug 2022 13:13:28 +0300 In-Reply-To: References: <20220803155011.43721-1-mlevitsk@redhat.com> <20220803155011.43721-14-mlevitsk@redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 X-Spam-Status: No, score=-2.1 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=ham 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-24 at 23:50 +0000, Sean Christopherson wrote: > On Wed, Aug 03, 2022, Maxim Levitsky wrote: > > @@ -518,7 +519,8 @@ struct kvm_smram_state_32 { > > u32 reserved1[62]; > > u32 smbase; > > u32 smm_revision; > > - u32 reserved2[5]; > > + u32 reserved2[4]; > > + u32 int_shadow; /* KVM extension */ > > Looking at this with fresh(er) eyes, I agree with Jim: KVM shouldn't add its own > fields in SMRAM. There's no need to use vmcb/vmcs memory either, just add fields > in kvm_vcpu_arch to save/restore the state across SMI/RSM, and then borrow VMX's > approach of supporting migration by adding flags to do out-of-band migration, > e.g. KVM_STATE_NESTED_SMM_STI_BLOCKING and KVM_STATE_NESTED_SMM_MOV_SS_BLOCKING. > > /* SMM state that's not saved in SMRAM. */ > struct { > struct { > u8 interruptibility; > } smm; > } nested; > > That'd finally give us an excuse to move nested_run_pending to common code too :-) > Paolo told me that he wants it to be done this way (save the state in the smram). My first version of this patch was actually saving the state in kvm internal state, I personally don't mind that much if to do it this way or another. But note that I can't use nested state - the int shadow thing has nothing to do with nesting. I think that 'struct kvm_vcpu_events' is the right place for this, and in fact it already has interrupt.shadow (which btw Qemu doesn't migrate...) My approach was to use upper 4 bits of 'interrupt.shadow' since it is hightly unlikely that we will ever see more that 16 different interrupt shadows. It would be a bit more clean to put it into the 'smi' substruct, but we already have the 'triple_fault' afterwards (but I think that this was very recent addition - maybe it is not too late?) A new 'KVM_VCPUEVENT_VALID_SMM_SHADOW' flag can be added to the struct to indicate the extra bits if you want. Best regards, Maxim Levitsky