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 F0727C43334 for ; Thu, 30 Jun 2022 06:00:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232674AbiF3GAy (ORCPT ); Thu, 30 Jun 2022 02:00:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46784 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230425AbiF3GAv (ORCPT ); Thu, 30 Jun 2022 02:00:51 -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 C39CEB7D6 for ; Wed, 29 Jun 2022 23:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656568849; 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=C6sLvcSkC4sYai7lQnjjjc7faknX9mP9HryqZU9+9oc=; b=jQNm8s22m4TwJscW4w4UyK92AXXNt9ZrcRHxjN3t8EDK7/y4AqlVY661eEZylxSeOL9aTL HynO0COazVB5DibfDOtxurjSzfnUl5XUFLuAyH8tyon8KNHI6vaCEDmH+w6Kv1QSVrVhrC E7VpUqE1BdyclC/4lAfMnoT747g4Oh0= 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-GCNN6YYLOfyDvhtlwV6bDA-1; Thu, 30 Jun 2022 02:00:46 -0400 X-MC-Unique: GCNN6YYLOfyDvhtlwV6bDA-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 5FF1B101A588; Thu, 30 Jun 2022 06:00:45 +0000 (UTC) Received: from starship (unknown [10.40.194.38]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4C389141510C; Thu, 30 Jun 2022 06:00:41 +0000 (UTC) Message-ID: <42da1631c8cdd282e5d9cfd0698b6df7deed2daf.camel@redhat.com> Subject: Re: [PATCH v2 11/11] KVM: x86: emulator/smm: preserve interrupt shadow in SMRAM From: Maxim Levitsky To: Jim Mattson Cc: kvm@vger.kernel.org, Sean Christopherson , x86@kernel.org, Kees Cook , Dave Hansen , linux-kernel@vger.kernel.org, "H. Peter Anvin" , Borislav Petkov , Joerg Roedel , Ingo Molnar , Paolo Bonzini , Thomas Gleixner , Vitaly Kuznetsov , Wanpeng Li Date: Thu, 30 Jun 2022 09:00:40 +0300 In-Reply-To: References: <20220621150902.46126-1-mlevitsk@redhat.com> <20220621150902.46126-12-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.7 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2022-06-29 at 09:31 -0700, Jim Mattson wrote: > On Tue, Jun 21, 2022 at 8:09 AM Maxim Levitsky wrote: > > When #SMI is asserted, the CPU can be in interrupt shadow > > due to sti or mov ss. > > > > It is not mandatory in Intel/AMD prm to have the #SMI > > blocked during the shadow, and on top of > > that, since neither SVM nor VMX has true support for SMI > > window, waiting for one instruction would mean single stepping > > the guest. > > > > Instead, allow #SMI in this case, but both reset the interrupt > > window and stash its value in SMRAM to restore it on exit > > from SMM. > > > > This fixes rare failures seen mostly on windows guests on VMX, > > when #SMI falls on the sti instruction which mainfest in > > VM entry failure due to EFLAGS.IF not being set, but STI interrupt > > window still being set in the VMCS. > > I think you're just making stuff up! See Note #5 at > https://sandpile.org/x86/inter.htm. > > Can you reference the vendors' documentation that supports this change? > First of all, just to note that the actual issue here was that we don't clear the shadow bits in the guest interruptability field in the vmcb on SMM entry, that triggered a consistency check because we do clear EFLAGS.IF. Preserving the interrupt shadow is just nice to have. That what Intel's spec says for the 'STI': "The IF flag and the STI and CLI instructions do not prohibit the generation of exceptions and nonmaskable inter- rupts (NMIs). However, NMIs (and system-management interrupts) may be inhibited on the instruction boundary following an execution of STI that begins with IF = 0." Thus it is likely that #SMI are just blocked when in shadow, but it is easier to implement it this way (avoids single stepping the guest) and without any user visable difference, which I noted in the patch description, I noted that there are two ways to solve this, and preserving the int shadow in SMRAM is just more simple way. As for CPUS that neither block SMI nor preserve the int shadaw, in theory they can, but that would break things, as noted in this mail https://lore.kernel.org/lkml/1284913699-14986-1-git-send-email-avi@redhat.com/ It is possible though that real cpu supports HLT restart flag, which makes this a non issue, still. I can't rule out that a real cpu doesn't preserve the interrupt shadow on SMI, but I don't see why we can't do this to make things more robust. Best regards, Maxim Levitsky