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 45CE6C4332F for ; Wed, 19 Oct 2022 22:19:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231418AbiJSWT2 (ORCPT ); Wed, 19 Oct 2022 18:19:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51958 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230350AbiJSWT0 (ORCPT ); Wed, 19 Oct 2022 18:19:26 -0400 Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 86AA2F2B for ; Wed, 19 Oct 2022 15:19:22 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id h2so11217970plb.2 for ; Wed, 19 Oct 2022 15:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=z4YnSEPLti5++1d+/gxvsHMlivYPnWvSShn2YRgOKDQ=; b=bgXvbpNck6JaVV+ruo1CFDxdJ7YsYPAD1ymB7Tqr6h2QPBc718SyOrorombXW5IUsH xIBydOXVYYgCtN/o1DfwN57WsmDx0gZ1BvrhW4SJos9tl7O8oXf8d+Lf+JMT5GyLaAwP T4q3oGEHY8d7kLecabPsnIElNYkRuBgap+u49+zBR05R3jz15Ed5iY3Nu2xs66s4NzDi 3I1KAhOTc80G0XAW2e8Xnst0JhBRHvwk7rHv32QCpP5x+YCK2u9CuURcW9b1jaiVGh3/ Esbo1Ta/Fcy6HG1MYPY3J+UD6eviKmmLvF2luSbWaUqD4dehRlrmMUYnDQz3WbbUWe6f W11Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=z4YnSEPLti5++1d+/gxvsHMlivYPnWvSShn2YRgOKDQ=; b=tlXIkX1CKj3lUWmteuXTG1AdMrPQlNLst+wV0bTHRaM2QfD4aWPseU4rjEoKYWxjrj c5iQ5L7hLUBvOZMshOF0Cc8DGWglgoixbNagdO6SV+xgY6duRWG1dJechDLbm0gj/OMM yo2W4kRHlbH0xY4UGzGvCdpRDSATbJkLaWlL78xi0HeRTu6AhCwiJ6GVpzQSunsBfvU/ yw5ERDYbVFK89wGm1X9qn9x4ug1GNxZn2ZULFk1rjCI0VukMLTLrcTbQBhlKv8/ToiZe RkG1ywpzgyMFN5MpPelKM7vNeExWUHl2XYmFiTKcugYvyVQEooMzu/aT3DokshAzjJ3K t63A== X-Gm-Message-State: ACrzQf2Gq1sLX0P7kqysGQ6F0FbPzv12Hw3qztP3JID4XaoB2SvsHeFC T7FrfgY1En9+nCMfopjQGMyV9A== X-Google-Smtp-Source: AMsMyM4wOGZ6Mzbvx+vtNxRRKJcvtr2w2MQf3Xv/TVwQqz9YK42hyOCsSWd9A7ktbshogZ+wXWYy/Q== X-Received: by 2002:a17:90b:4c42:b0:20d:7820:2e4e with SMTP id np2-20020a17090b4c4200b0020d78202e4emr47808393pjb.40.1666217961925; Wed, 19 Oct 2022 15:19:21 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id x7-20020a170902a38700b0017e93c158d7sm11141360pla.214.2022.10.19.15.19.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Oct 2022 15:19:21 -0700 (PDT) Date: Wed, 19 Oct 2022 22:19:18 +0000 From: Sean Christopherson To: Vitaly Kuznetsov Cc: kvm@vger.kernel.org, Paolo Bonzini , Wanpeng Li , Jim Mattson , Michael Kelley , Siddharth Chandrasekaran , Yuan Yao , Maxim Levitsky , linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v11 44/46] KVM: selftests: evmcs_test: Introduce L2 TLB flush test Message-ID: References: <20221004123956.188909-1-vkuznets@redhat.com> <20221004123956.188909-45-vkuznets@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221004123956.188909-45-vkuznets@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-hyperv@vger.kernel.org On Tue, Oct 04, 2022, Vitaly Kuznetsov wrote: > @@ -64,15 +67,33 @@ void l2_guest_code(void) > vmcall(); > rdmsr_gs_base(); /* intercepted */ > > + /* L2 TLB flush tests */ > + hyperv_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE | HV_HYPERCALL_FAST_BIT, 0x0, > + HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES | HV_FLUSH_ALL_PROCESSORS); Alignment is funky. > + rdmsr_fs_base(); > + /* > + * Note: hypercall status (RAX) is not preserved correctly by L1 after > + * synthetic vmexit, use unchecked version. Nice... > + */ > + __hyperv_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE | HV_HYPERCALL_FAST_BIT, 0x0, > + HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES | HV_FLUSH_ALL_PROCESSORS, > + &unused); > + /* Make sure we're no issuing Hyper-V TLB flush call again */ > + __asm__ __volatile__ ("mov $0xdeadbeef, %rcx"); > + > /* Done, exit to L1 and never come back. */ > vmcall(); > } > > -void guest_code(struct vmx_pages *vmx_pages, struct hyperv_test_pages *hv_pages) > +void guest_code(struct vmx_pages *vmx_pages, struct hyperv_test_pages *hv_pages, > + vm_vaddr_t hv_hcall_page_gpa) > { > #define L2_GUEST_STACK_SIZE 64 > unsigned long l2_guest_stack[L2_GUEST_STACK_SIZE]; > > + wrmsr(HV_X64_MSR_GUEST_OS_ID, HYPERV_LINUX_OS_ID); > + wrmsr(HV_X64_MSR_HYPERCALL, hv_hcall_page_gpa); > + > x2apic_enable(); > > GUEST_SYNC(1); > @@ -102,6 +123,14 @@ void guest_code(struct vmx_pages *vmx_pages, struct hyperv_test_pages *hv_pages) > vmwrite(PIN_BASED_VM_EXEC_CONTROL, vmreadz(PIN_BASED_VM_EXEC_CONTROL) | > PIN_BASED_NMI_EXITING); > > + /* L2 TLB flush setup */ > + current_evmcs->partition_assist_page = hv_pages->partition_assist_gpa; > + current_evmcs->hv_enlightenments_control.nested_flush_hypercall = 1; > + current_evmcs->hv_vm_id = 1; > + current_evmcs->hv_vp_id = 1; > + current_vp_assist->nested_control.features.directhypercall = 1; > + *(u32 *)(hv_pages->partition_assist) = 0; > + > GUEST_ASSERT(!vmlaunch()); Pre-existing code, but would it make sense to add an assert here to verify L2 exited due to an NMI? Feel free to ignore this for now if it's not straightforward, this series is plenty big :-)