From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 8366781C8D for ; Wed, 9 Nov 2016 03:30:06 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id t79so294410880wmt.0 for ; Wed, 09 Nov 2016 03:30:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=5mNyzptYK4RN0cX1snBPiQPticOKa3jOvUXBDXU1+Hg=; b=m/gRErC/O94oGwZfUhDpvaqX9HccI738S6uwIUZINCLXuyCbQCby/mw89+ksPBz6jB AmjNlTkE3Uo02jyKGhRHW/WkVfLx0QoBb2R28PYz8hz2aQ9Lr2TTFL5M+3n4/40vWWXI 7l8tBHX3aIa/+WM1akc5tuE1Qj8yMGQ9FMlmb9BhEY4URh6yKScdSK24amzAhPJTLOfo K1bl2ixM5xUswyiwwD/RD0fvu5utAMk6yUPYVGb1xo1zvz+hVmo5cNKtmN7cQlLyjcZf 434lrDOqtLj+zEowagwavF2W4abzqxj4aBszv4vdSSwJH4ai97Sa0p/9lxXrD3dlbg02 dKBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=5mNyzptYK4RN0cX1snBPiQPticOKa3jOvUXBDXU1+Hg=; b=AlUapMpa21kw8iHJ95dsW4Zm/HFT0T8Yv4jwXcFvIScQMXc08xs0PiDJCQr1ZTXSfX 3s7RI68/9+3lXaxDK/ub8t7Os2wiPCJ341Ee/yZvcrZ9XHlXS6G5fsbdaf/9yQuwNcnu 8W7cdJKICH/lUPc8rLZ9IFhj3JJpm5NoTssi1Gh/GRhgG43rKIsmMnDTamR5+oD4rCeC SpUpQdImO8HNDjoVw/jD/+ViX4qc/e6+gYhPxZD0cohc2Xfz7yxEzZhTxwKuX9pbThua /RkUUKer9CmlqQa+CDVxiG3kJLB1M9qvF7UT6TS+CwslbgUbJ/v2SjieySm6LpF1l2XR LZeQ== X-Gm-Message-State: ABUngveCdJ9NcFaUBrqvSO4nI8IwXYbjRdejFz/Lua2D+D9j32nox3U8LICLJ4NPg/Yv1Q== X-Received: by 10.28.87.85 with SMTP id l82mr16502720wmb.99.1478691008375; Wed, 09 Nov 2016 03:30:08 -0800 (PST) Received: from [192.168.10.165] (94-39-185-129.adsl-ull.clienti.tiscali.it. [94.39.185.129]) by smtp.googlemail.com with ESMTPSA id l67sm6418355wmf.20.2016.11.09.03.30.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Nov 2016 03:30:07 -0800 (PST) Sender: Paolo Bonzini To: "Yao, Jiewen" , Laszlo Ersek References: <1478251854-14660-1-git-send-email-jiewen.yao@intel.com> <08406bf5-4377-63a1-8dd9-34479c015d4b@redhat.com> <74D8A39837DF1E4DA445A8C0B3885C50386C0CB8@shsmsx102.ccr.corp.intel.com> Cc: "Tian, Feng" , "edk2-devel@ml01.01.org" , "Kinney, Michael D" , "Fan, Jeff" , "Zeng, Star" From: Paolo Bonzini Message-ID: Date: Wed, 9 Nov 2016 12:30:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C50386C0CB8@shsmsx102.ccr.corp.intel.com> Subject: Re: [PATCH V2 0/6] Enable SMM page level protection. X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 11:30:06 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 09/11/2016 07:25, Yao, Jiewen wrote: > Current BSP just uses its own context to initialize AP. So that AP > takes BSP CR3, which is SMM CR3, unfortunately. After BSP initialized > APs, the AP is put to HALT-LOOP in X64 mode. It is the last straw, > because X64 mode halt still need paging. > > 3) The error happen, once the AP receives an interrupt (for > whatever reason), AP starts executing code. However, that that time > the AP might not be in SMM mode. It means SMM CR3 is not available. > And then we see this. > > 4) I guess we did not see the error, or this is RANDOM issue, > because it depends on if AP receives an interrupt before BSP send > INIT-SIPI-SIPI. > > 5) The fix, I think, should be below: We should always put AP to > protected mode, so that no paging is needed. We should put AP in > above 1M reserved memory, instead of <1M memory, because <1M memory > is restored. For what it's worth, this is not what I observed. What I found is that the BSP doesn't wait for the AP rendezvous before closing SMRAM. I'm not sure if the two things are related, but (3) would be a much worse bug. APs should not be receiving an interrupt. Perhaps an NMI if API is sitting in a CLI;HLT loop, but this is not what is happening. Paolo