Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp157170pxb; Thu, 7 Apr 2022 01:50:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxgJ+UVav0A0hI8l7qEJB9WoYxHffK+hq3yZ2jPwLw++UPb+rZof0KizWUbMhx47Pzi7ZdM X-Received: by 2002:a65:5605:0:b0:399:4e2f:413d with SMTP id l5-20020a655605000000b003994e2f413dmr10240434pgs.504.1649321410354; Thu, 07 Apr 2022 01:50:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649321410; cv=none; d=google.com; s=arc-20160816; b=WrIjPVoBDY5XOm8XdiNICap50hMxRB/HofeyoKd0ptZ+z7der6obnZ8d6Qq9KH5J8s FOB9EqkcgjQ/8ob/K62/zrtxO7TER22hr5A6OX69CToVAUKjZ9Y4U/hLC1uSxO3FdYQq Im0N8wjfGgQp3wMkVPjPEIhiBH7qpFzyKVA4bVMn8yKdIx3nLGpS0jB3LFJyQhEIvMt7 VG2rq4B19GfEhrviRh7j3+mbaoCDnRJy1gKDMcBEO4mVK9JPvp+Fnrl7eN9Pf89wzr23 PDyg9I5fqLLCE4p4/YRWFGspmyc7KKCVOBNFkGGyU3ZGXmeU4O/pp3zFtqCmJkWtwJ4/ fVvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=mOcFjdp+y1Sz6896UR5N49lHd8ZQC35tXeavwsI5S1s=; b=adv1WUdKjiG6i0VgDeywRrGq7uPflmn10C2CJJtDC76Lp1JNQj+BF7FbdDX5BwU+zo gEM9djkmqG6WO3btO0A8AylcqC1vmLF+MTvzHP+w/tzbDSy3yU+VvTC3D/VTtMWte7sS 8rJ1++jWt6w0RA3tdd90nNlqmGCtCRGLG3AxB3gXNWb3gAusEo1QITD476zRaW/aVu9R deJQQpMI6psuYGa7RdGQZUA9//NAWJs3nfcmuWMoHcHDXoH68ekjFJOQ+3jVPS/OMasM lbLbAU0D+zVARY+wfxbE+Gy30u65YNGRXKmWfhyc0aL1Ciihe2cKVZZwJurfiHSURUXN 4UpQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=AZ7Q1KjS; 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=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bj27-20020a056a02019b00b0039942b974b1si10093381pgb.303.2022.04.07.01.49.57; Thu, 07 Apr 2022 01:50:10 -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=@intel.com header.s=Intel header.b=AZ7Q1KjS; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240936AbiDGGPE (ORCPT + 99 others); Thu, 7 Apr 2022 02:15:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240378AbiDGGPD (ORCPT ); Thu, 7 Apr 2022 02:15:03 -0400 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 156851C8DB8; Wed, 6 Apr 2022 23:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649311985; x=1680847985; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=C3nT1yCtjX7kKzPi6gJkoB5VNcsfCgvLH5dyegPN6I0=; b=AZ7Q1KjSjGWovTeacTWtTQTzf9y+6shEcM4s5gwj0jxmzqemI/laNZVf sL1Ly/2qzvJ957nto0X0fQZfCQrtocD+AAtgTMA6dJaDFJ3uckNjJtt+L vGbZYQwmNhvzSGrolDfIw4FaRFNNtEQ0jspnqiI+L6TLZnkC3+M3BOYaZ Ny4QixdwjEl1WT7WszXjmLYJkhY37elpv1tpbQ8Y8RT7bRMZJ/eG62wFW bcdozJYypEYIooO+ixVduf6+0wFHNTJ2pXwYtLo6Odl2D6nzzubb9OqJt XmG2piGTqSZVtJqWc8P9pnijgfbtHdPKnUJv3S7KwoHU3sdcGxfUORIRj g==; X-IronPort-AV: E=McAfee;i="6200,9189,10309"; a="243373080" X-IronPort-AV: E=Sophos;i="5.90,241,1643702400"; d="scan'208";a="243373080" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2022 23:13:04 -0700 X-IronPort-AV: E=Sophos;i="5.90,241,1643702400"; d="scan'208";a="549880694" Received: from cqiang-mobl.ccr.corp.intel.com (HELO [10.249.174.148]) ([10.249.174.148]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2022 23:13:01 -0700 Message-ID: <8347e6e3-5b22-c9c9-5e6b-9ea33c614d5a@intel.com> Date: Thu, 7 Apr 2022 14:12:59 +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 v5 1/3] KVM: X86: Save&restore the triple fault request Content-Language: en-US To: Sean Christopherson Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Xiaoyao Li , kvm@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220318074955.22428-1-chenyi.qiang@intel.com> <20220318074955.22428-2-chenyi.qiang@intel.com> From: Chenyi Qiang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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 4/7/2022 5:15 AM, Sean Christopherson wrote: > On Tue, Apr 05, 2022, Sean Christopherson wrote: >> On Tue, Apr 05, 2022, Sean Christopherson wrote: >>> On Fri, Mar 18, 2022, Chenyi Qiang wrote: >>>> @@ -4976,6 +4980,9 @@ static int kvm_vcpu_ioctl_x86_set_vcpu_events(struct kvm_vcpu *vcpu, >>>> } >>>> } >>>> >>>> + if (events->flags & KVM_VCPUEVENT_TRIPLE_FAULT) >>>> + kvm_make_request(KVM_REQ_TRIPLE_FAULT, vcpu); >>>> + >>>> kvm_make_request(KVM_REQ_EVENT, vcpu); >>> >>> Looks correct, but this really needs a selftest, at least for the SET path since >>> the intent is to use that for the NOTIFY handling. Doesn't need to be super fancy, >>> e.g. do port I/O from L2, inject a triple fault, and verify L1 sees the appropriate >>> exit. >>> >>> Aha! And for the GET path, abuse KVM_X86_SET_MCE with CR4.MCE=0 to coerce KVM into >>> making a KVM_REQ_TRIPLE_FAULT, that way there's no need to try and hit a timing >>> window to intercept the request. >> >> Drat, I bet that MCE path means the WARN in nested_vmx_vmexit() can be triggered >> by userspace. If so, this patch makes it really, really easy to hit, e.g. queue the >> request while L2 is active, then do KVM_SET_NESTED_STATE to force an "exit" without >> bouncing through kvm_check_nested_events(). >> >> WARN_ON_ONCE(kvm_check_request(KVM_REQ_TRIPLE_FAULT, vcpu)) >> >> I don't think SVM has a user-triggerable WARN, but the request should still be >> dropped on forced exit from L2, e.g. I believe this is the correct fix: > > Confirmed the WARN can be triggered by abusing this patch, I'll get a patch out > once I figure out why kvm/queue is broken. > > diff --git a/tools/testing/selftests/kvm/x86_64/state_test.c b/tools/testing/selftests/kvm/x86_64/state_test.c > index 2e0a92da8ff5..b7faeae3dcc4 100644 > --- a/tools/testing/selftests/kvm/x86_64/state_test.c > +++ b/tools/testing/selftests/kvm/x86_64/state_test.c > @@ -210,6 +210,12 @@ int main(int argc, char *argv[]) > memset(®s1, 0, sizeof(regs1)); > vcpu_regs_get(vm, VCPU_ID, ®s1); > > + if (stage == 6) { > + state->events.flags |= 0x20; > + vcpu_events_set(vm, VCPU_ID, &state->events); > + vcpu_nested_state_set(vm, VCPU_ID, &state->nested, false); > + } > + > kvm_vm_release(vm); > > /* Restore state in a new VM. */ Also verified the WARN with this. Then, is it still necessary to add an individual selftest about the working flow of save/restore triple fault event? >