Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v5 4/6] KVM: SVM: Add support to handle AP reset MSR
 protocol
To:     Sean Christopherson <seanjc@google.com>,
        Joerg Roedel <joro@8bytes.org>
Cc:     Paolo Bonzini <pbonzini@redhat.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>, x86@kernel.org,
        Brijesh Singh <brijesh.singh@amd.com>, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, Joerg Roedel <jroedel@suse.de>
References: <20211020124416.24523-1-joro@8bytes.org>
 <20211020124416.24523-5-joro@8bytes.org> <YXBUlYll8JDjH/Wd@google.com>
From:   Tom Lendacky <thomas.lendacky@amd.com>
Message-ID: <2ae35ebd-aaed-a3df-c74e-5a3be378b8af@amd.com>
Date:   Wed, 20 Oct 2021 13:36:15 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
In-Reply-To: <YXBUlYll8JDjH/Wd@google.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?Windows-1252?Q?J/n4VU0iPuJGCLBuaGM0iipc0kGPVxMGZm7L0RuAtrG7zJe9Ua6exnF6?=
 =?Windows-1252?Q?hdQUbJFR0IhMkW8n8K4pqaGnlNb4sAHsBe36cBsRAU4Y/D+c1v6uQ7H2?=
 =?Windows-1252?Q?DTiiAU/hGdxIoAvWJ1ep4ICZ7P/4z1pZVpngZ++81Uy38jNAsLd9B2A+?=
 =?Windows-1252?Q?ULI5a83no6zETOfpctc3AhVxicfnR8hqmaVKPd7rdxlwwtZvdftJ4QV7?=
 =?Windows-1252?Q?4tZolalCLsX7fe6JayXn4nnFV5pN6XVPA7wuqdvOIvQPDs7X7AOTwChD?=
 =?Windows-1252?Q?zVVHEnd2A/L1KUHUPOfFrPjragiEmjvTmcDm33FsBAghHScsCdB/PP2w?=
 =?Windows-1252?Q?IbLWn3Z0QGyXXxk6JSOQiNiHkJlbM7jYBXR/5GVtBcN8IjzFG2cszDYY?=
 =?Windows-1252?Q?C4dFLeQ+oYwM+OTgJnUCncUEwGH5fark6OTHL3BIpeSTTSvwYyfCPhB3?=
 =?Windows-1252?Q?vXlEg7rR7mlnaaKNXpo0dTSWrRApdJJL6A1WjdvdYzR9hZT1TQX8h9O5?=
 =?Windows-1252?Q?Gd2AX3KfUr5zMG1WYzDajZv2Qv0+z9bFZxVzeRm2dUD/+QopJawQuPCG?=
 =?Windows-1252?Q?DUEGqDAvBgqmJx5RKblia0tVUwZXK3XDD6Fl2ieYJsQvK47hKoJD2/Ht?=
 =?Windows-1252?Q?X1RGB0aPptrQT8J/Kwg4pevgdqqjchocJyiN0phLdlL9YJfQgIRkObTw?=
 =?Windows-1252?Q?bx06asGvY9h+KByY3VXB6LJNJEx+1hrxmy1tUyksKTgACBgWBdYQqoQA?=
 =?Windows-1252?Q?TzllerWJqzvdNGlvxJe5waxTSftpQh8EO7+HyGNNd4/g4/XvwfjUzO52?=
 =?Windows-1252?Q?FV74DZsgE/anonZHdZJp++x1OOf7o9+h0iUGD9orEkvt53oBsvWwered?=
 =?Windows-1252?Q?RDvm3HB6We3Ls6ZAJcLbLkWMbWY6ORNgDp4QWRbkGI/G2VFvz4Sd66Hq?=
 =?Windows-1252?Q?X4I8T6HS/vBm7VKJWA+M3YvB6XghJW3sSLQVmn992ZlOfwfG82g05KAs?=
 =?Windows-1252?Q?w9bFTFJ9px8o0ZOfO4hH2LAvDRmJPlG9e0M51+oEM3+lxvEnwE3lOeIZ?=
 =?Windows-1252?Q?jfcy67OZTF2POzsb9dcluK3NhbcOqb9MrnH9yYCvCsswAOWsBd/pfcwr?=
 =?Windows-1252?Q?FNTxjmEzxHSU+yp2OA7gYAYwFVDd3d2jMbo7BcSZxWQ1Phc+j5LDfIXO?=
 =?Windows-1252?Q?TXyHnlVD7wIG62yMjZTE/6J0w5mbKnyLpd3A0naujJxxE1Z46E5bcdx4?=
 =?Windows-1252?Q?NA3ojVOQ3ePz/5pn0GSNUGOJvdbKFlKl5UOaasMg3m72c4Nny29L10qC?=
 =?Windows-1252?Q?JMejIG2HqDG3D3FFM++kfsiEyZxp6b7M97KJaKlqwvz/4lTgV4aLFfvD?=
 =?Windows-1252?Q?bDlqUrixfr1Q8zXHNuMfFQ9M/wqPJq5iSYDINb9viIWJt/VFHDYTvTwO?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a190dd46-ca02-4eda-c53f-08d993f8815a
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5229.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2021 18:36:18.2441
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: tlendack@amd.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5232
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 10/20/21 12:40 PM, Sean Christopherson wrote:
> On Wed, Oct 20, 2021, Joerg Roedel wrote:
> 
> Tying into above, handling this in SIPI is flawed.  For example, if the guest
> does INIT-SIPI-SIPI without a reset hold, KVM would incorrect set sw_exit_info_2
> on the SIPI.  Because this mess requires an INIT, KVM has lost track of whether
> the guest was in KVM_MP_STATE_AP_RESET_HOLD and thus can't know if the SIPI
> arrived after a reset hold.  Looking at KVM, IIUC, this bug is why the hack
> "received_first_sipi" exists.

The received_first_sipi is because the APs have to be started the very 
first time in the traditional way. The AP can't issue an AP reset hold if 
it hasn't started to begin with in which case there would be no GHCB mapped.

After the check to see if the  GHCB is mapped was added to 
sev_vcpu_deliver_sipi_vector(), the "received_first_sipi" could probably 
have been deleted at that point.

Thanks,
Tom