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 39C0CC433F5 for ; Thu, 7 Apr 2022 08:42:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243211AbiDGIoR (ORCPT ); Thu, 7 Apr 2022 04:44:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243200AbiDGIoL (ORCPT ); Thu, 7 Apr 2022 04:44:11 -0400 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 035625DE76; Thu, 7 Apr 2022 01:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649320931; x=1680856931; h=message-id:date:mime-version:subject:from:to:cc: references:in-reply-to:content-transfer-encoding; bh=yy+cT/a1EMFV/vsEI4YTD6dp4j+4Ch2HlkBQzyfLhT4=; b=Gj28QSS3gxZx1AU7aoJ6GOLhq5kuehve13weHUKlmXxihvG4XpeE6Q2/ +hXB+Pzw5AJSbW84JCVJypOam65HHlUyjWoJqRfBVxfWy5ua4QwPKdl4i nG29IayLzE06pS3eSbZQV0c2WZueUyFBxKTwuVpjQRxzWMuN5ToD1yGpp w9bJ9xkgUSmTb+UhIzwd6//jZW3fTFToOXM5gVp/bgyb3jFXNDIH9pKFn bn2wo30CzGu7GsmhE1kyenz6oTj2BYqMVBer8WK1/nSqKY8Keea5kbtro BbUadHWOv4TghYMcnq3/zeKbwg0hckKuS+y4Dp1nufeNWrAxUhJOqztyN g==; X-IronPort-AV: E=McAfee;i="6200,9189,10309"; a="261443694" X-IronPort-AV: E=Sophos;i="5.90,241,1643702400"; d="scan'208";a="261443694" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2022 01:42:11 -0700 X-IronPort-AV: E=Sophos;i="5.90,241,1643702400"; d="scan'208";a="722872202" Received: from xiaoyaol-hp-g830.ccr.corp.intel.com (HELO [10.255.28.125]) ([10.255.28.125]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2022 01:42:09 -0700 Message-ID: <55f6f971-94ef-00d8-6f99-c040b103d56f@intel.com> Date: Thu, 7 Apr 2022 16:42:06 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.7.0 Subject: Re: [PATCH 3/3] KVM: nVMX: Clear IDT vectoring on nested VM-Exit for double/triple fault Content-Language: en-US From: Xiaoyao Li To: Sean Christopherson , Paolo Bonzini Cc: Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Chenyi Qiang References: <20220407002315.78092-1-seanjc@google.com> <20220407002315.78092-4-seanjc@google.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/7/2022 4:02 PM, Xiaoyao Li wrote: > On 4/7/2022 8:23 AM, Sean Christopherson wrote: >> Clear the IDT vectoring field in vmcs12 on next VM-Exit due to a double >> or triple fault.  Per the SDM, a VM-Exit isn't considered to occur during >> event delivery if the exit is due to an intercepted double fault or a >> triple fault.  Opportunistically move the default clearing (no event >> "pending") into the helper so that it's more obvious that KVM does indeed >> handle this case. >> >> Note, the double fault case is worded rather wierdly in the SDM: >> >>    The original event results in a double-fault exception that causes the >>    VM exit directly. >> >> Temporarily ignoring injected events, double faults can _only_ occur if >> an exception occurs while attempting to deliver a different exception, >> i.e. there's _always_ an original event.  And for injected double fault, >> while there's no original event, injected events are never subject to >> interception. >> >> Presumably the SDM is calling out that a the vectoring info will be valid >> if a different exit occurs after a double fault, e.g. if a #PF occurs and >> is intercepted while vectoring #DF, then the vectoring info will show the >> double fault. > > Wouldn't it be a tripe fault exit in this case? It won't since #PF is intercepted by exception bitmap in your case. >> In other words, the clause can simply be read as: >> >>    The VM exit is caused by a double-fault exception. >