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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DA140C48BC3 for ; Wed, 21 Feb 2024 05:43:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 64EA46B006E; Wed, 21 Feb 2024 00:43:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FFD76B0071; Wed, 21 Feb 2024 00:43:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A0006B0072; Wed, 21 Feb 2024 00:43:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 365636B006E for ; Wed, 21 Feb 2024 00:43:18 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BD50B16094D for ; Wed, 21 Feb 2024 05:43:17 +0000 (UTC) X-FDA: 81814718034.25.F0BFC5C Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) by imf27.hostedemail.com (Postfix) with ESMTP id 15D9F4000B for ; Wed, 21 Feb 2024 05:43:14 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=g9OTfNKc; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf27.hostedemail.com: domain of binbin.wu@linux.intel.com has no SPF policy when checking 198.175.65.18) smtp.mailfrom=binbin.wu@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708494195; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=bRfhrg5m9fECifPf2lEz4MJbRYOrG46N8chw5awAYP8=; b=EtLzbis9KZF+QA3HjFU2pNINz6hkgU66Vmjf53PeS/16zDUwkGYb6zRmb9K00r1Ozwq0VZ Uofue/ajq0HPkXgFgicDK3QUFMQABvJIaXJjLznEpnbfpKBGCpEtavDaKRsNnq22GjEZ6K 6FFSpeSv4pMHIQN1YTcrvNQuLegtzOU= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=g9OTfNKc; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf27.hostedemail.com: domain of binbin.wu@linux.intel.com has no SPF policy when checking 198.175.65.18) smtp.mailfrom=binbin.wu@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708494195; a=rsa-sha256; cv=none; b=NtTQcd5Z1vYOy5oo/HYxff/MktlDjmtHSOLEySwc/Fk5Xev7rweIr2t3mVnlb4w7oUuMzu NCJEBziu7jlwMJ1w76NBfYAjs3t6YWZ+DGBmauyixg1zLPTBOhOwA9HSJDFeK19IuuRqCN hAqsYEbfGWtnZHNgJheFB2Ej1+xrOOA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708494195; x=1740030195; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Uukhj9fpIxxRlYAD8QGrCgdODLB1OI42Ei20zSHeD8g=; b=g9OTfNKcCinIg6ZpSZuwbhyXfoBioVDAa3zhpUHtDjrnlvAduTKja5Sw 3pYHYh/OyRP1UQURigL5iLkUjhgvNmcQ/0A205ePx+vsBOjZCJQCOAxlT XtNKbjjTR8wgjT8o3vB1MCb6pzWYlsJcw9WaH/JJF3HwQrIzXl8LynreU zWf4WdWe7VWTsQtYDRMJNCtKDkn0l5zYofXqlAv/FSR2uK968QTldWwU+ p9mtdlp9qiuIDeSf6H/anxR+tKf65dwVwp61/SlvUbCqdIhbrHij915nU 7ZIWc3IosnS9jrMX0w8BL5isXexQS8djx00vedwwZxRogJy1Saspe8BC0 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10990"; a="2749578" X-IronPort-AV: E=Sophos;i="6.06,174,1705392000"; d="scan'208";a="2749578" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Feb 2024 21:43:14 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,174,1705392000"; d="scan'208";a="28172586" Received: from binbinwu-mobl.ccr.corp.intel.com (HELO [10.93.18.46]) ([10.93.18.46]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Feb 2024 21:43:09 -0800 Message-ID: <5749ff16-ca81-440d-85f0-62a1c3a572d0@linux.intel.com> Date: Wed, 21 Feb 2024 13:43:06 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v5 04/29] KVM: selftests: Refactor steps in vCPU descriptor table initialization To: Sagi Shahar Cc: linux-kselftest@vger.kernel.org, Ackerley Tng , Ryan Afranji , Erdem Aktas , Isaku Yamahata , Sean Christopherson , Paolo Bonzini , Shuah Khan , Peter Gonda , Haibo Xu , Chao Peng , Vishal Annapurve , Roger Wang , Vipin Sharma , jmattson@google.com, dmatlack@google.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org References: <20231212204647.2170650-1-sagis@google.com> <20231212204647.2170650-5-sagis@google.com> From: Binbin Wu In-Reply-To: <20231212204647.2170650-5-sagis@google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: dto9qqr8rdunz8aikdred379wsg4ktbf X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 15D9F4000B X-HE-Tag: 1708494194-322462 X-HE-Meta: U2FsdGVkX19O6DBx8yI38a1Fbeduxb2YqOMJQjPKpjbe8bd9LMqZnk+HKkNfnDpnq7o2pJjd531QxGbveE7GBdo/Sd29wVXJbkQqHSIR8yEHO0a0hJq0lja3JQkxiL5RExl+3oOMCtUYNw0I+hXTQ369c2ekvrnJmMeJpqKd1Hjhv4NNmjZ9rJQWgiZuvX9f6+aMlGyDAhIlw4d4qY/01ww4uNoMdwm7Vp+O3L4OS4RMM5+gQUuMbg74oV6YFcbAfNdw/1tK1ciJ50bNZ/yuKGJZVS31wrvmWVfMtn4miAgel9am6PXMvlrEsW6CuyqGbZq0kdELr2efDKdro9POV28+6vANzpWr9D5dgfdo9frsl2+nb1FdRY4SilAhOZCVGtPoOXl2m7UKuFrLViTZx7P0m7EePyQnwBXznXPo0kdPPvMw5J1X4BmSYrLllIbuUvcteLAMXTq9KdRe8hA+HAaWNKByH0slq2uVWxzheKbgTajVjDUN23gN4xkb+Dhq2cCYU70uOKHEu85/diALsSVru7AgSeRw23oQqOpJhxzfQ/9Yx8SGHcSMTm3ZjgRpW8xK/uCxZz3V1IHK+3ridpxm1EvWz4WhVKKhO+6810nW0yOGQNKgOhRMa6CVFlNtMU1rijcUyXjnl1FIi7NdiWCzvKJmj2C51ixW05rdszGpYsD5hbUGnY3KyCR9FZQEAnjaTR1EmhNnf1hcH7xXGAvnBB0NuyRDCnBKQZEl9cZ7jqcwPzwG7knL8DpQq1+eHdK3QWhBwmDcX6jvjRtpd5MW7n0wnJEPa36LsJEB4/1TWhcOfxxfg4YSAA+Z6+NYbWbK7+uhpQcoWDK2jbRhYyboieUz3hGsbb6fkaPPXltb6Mcxb2dS8BBR3slF47MWa04lX2UB9jVOYEQn69rRYN51WzWfBhWgOy5D3eR5cD+95o1vWRNMTejXggmpBH0C4YuzCFvg0QONdonBZ7O HID6sXGI gBeL7R6w1i57cjRjrz1Cr8JMV8dSJzoV3x1/jdpktwB5DcmiK66s6Pg/vZJQNGQgW9LY631yWvTBDyMB3Sfv8fXpE5Qb92LNo1fbMX4DSmJ9AmmxkeKQ5gj3CBEmd9NlB806pDz9AfDjCFnOAb2K2xCU22LaOTQ/bNd/FKXLv5ZODegddFBek7xu+8XkeedZFxhYqUymgHVkYSngPLtOgwVlVgFi39heO3hYQ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 12/13/2023 4:46 AM, Sagi Shahar wrote: > From: Ackerley Tng > > Split the vCPU descriptor table initialization process into a few > steps and expose them: > > + Setting up the IDT > + Syncing exception handlers into the guest > > In kvm_setup_idt(), we conditionally allocate guest memory for vm->idt > to avoid double allocation when kvm_setup_idt() is used after > vm_init_descriptor_tables(). > > Signed-off-by: Ackerley Tng > Signed-off-by: Ryan Afranji > Signed-off-by: Sagi Shahar > --- > .../selftests/kvm/include/x86_64/processor.h | 2 ++ > .../selftests/kvm/lib/x86_64/processor.c | 19 ++++++++++++++++--- > 2 files changed, 18 insertions(+), 3 deletions(-) > > diff --git a/tools/testing/selftests/kvm/include/x86_64/processor.h b/tools/testing/selftests/kvm/include/x86_64/processor.h > index 0b8855d68744..5c4e9a27d9e2 100644 > --- a/tools/testing/selftests/kvm/include/x86_64/processor.h > +++ b/tools/testing/selftests/kvm/include/x86_64/processor.h > @@ -1089,6 +1089,8 @@ struct idt_entry { > uint32_t offset2; uint32_t reserved; > }; > > +void kvm_setup_idt(struct kvm_vm *vm, struct kvm_dtable *dt); > +void sync_exception_handlers_to_guest(struct kvm_vm *vm); > void vm_init_descriptor_tables(struct kvm_vm *vm); > void vcpu_init_descriptor_tables(struct kvm_vcpu *vcpu); > void vm_install_exception_handler(struct kvm_vm *vm, int vector, > diff --git a/tools/testing/selftests/kvm/lib/x86_64/processor.c b/tools/testing/selftests/kvm/lib/x86_64/processor.c > index b6b9438e0a33..566d82829da4 100644 > --- a/tools/testing/selftests/kvm/lib/x86_64/processor.c > +++ b/tools/testing/selftests/kvm/lib/x86_64/processor.c > @@ -1155,19 +1155,32 @@ void vm_init_descriptor_tables(struct kvm_vm *vm) > DEFAULT_CODE_SELECTOR); > } > > +void kvm_setup_idt(struct kvm_vm *vm, struct kvm_dtable *dt) > +{ > + if (!vm->idt) > + vm->idt = vm_vaddr_alloc_page(vm); IDT is allocated in DATA memslot in current code, but here, when using vm_vaddr_alloc_page(), it will be allocated in TEST_DATA memslot. Do we need to follow the current code to use __vm_vaddr_alloc_page(vm, MEM_REGION_DATA) instead? > + > + dt->base = vm->idt; > + dt->limit = NUM_INTERRUPTS * sizeof(struct idt_entry) - 1; > +} > + > +void sync_exception_handlers_to_guest(struct kvm_vm *vm) > +{ > + *(vm_vaddr_t *)addr_gva2hva(vm, (vm_vaddr_t)(&exception_handlers)) = vm->handlers; > +} > + > void vcpu_init_descriptor_tables(struct kvm_vcpu *vcpu) > { > struct kvm_vm *vm = vcpu->vm; > struct kvm_sregs sregs; > > vcpu_sregs_get(vcpu, &sregs); > - sregs.idt.base = vm->idt; > - sregs.idt.limit = NUM_INTERRUPTS * sizeof(struct idt_entry) - 1; > + kvm_setup_idt(vcpu->vm, &sregs.idt); > sregs.gdt.base = vm->gdt; > sregs.gdt.limit = getpagesize() - 1; > kvm_seg_set_kernel_data_64bit(NULL, DEFAULT_DATA_SELECTOR, &sregs.gs); > vcpu_sregs_set(vcpu, &sregs); > - *(vm_vaddr_t *)addr_gva2hva(vm, (vm_vaddr_t)(&exception_handlers)) = vm->handlers; > + sync_exception_handlers_to_guest(vm); > } > > void vm_install_exception_handler(struct kvm_vm *vm, int vector,