Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp5661644rdb; Wed, 13 Dec 2023 15:57:54 -0800 (PST) X-Google-Smtp-Source: AGHT+IEgDYEYXJ7WS6NUW62psM3siBaeKuwuHY2mjRovwARHGXDq9pR8FxvXIt2N+JHv0geTaUSi X-Received: by 2002:a05:6a00:b87:b0:6ce:6f21:566c with SMTP id g7-20020a056a000b8700b006ce6f21566cmr11518150pfj.7.1702511873807; Wed, 13 Dec 2023 15:57:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702511873; cv=none; d=google.com; s=arc-20160816; b=EUixyP/u7yF/1ziwbeVw2SoLuzkRoxPi0bRxhDsBThjIc1LWHdYXKMLFdKR/y9ssiQ 2u+YBySQNHVlKSW0vNe1aH1UMFsgzTDBEaG/vEFwkpi6bk5Uk0PqZDzHtG5c5QxITyZz Cm3aK7LHA3ok6QAPmASQfbTwCtRh1sFRhOkfa/E/DHCn2GAPeBUEK85tV3vhBbbaO0U5 N0oZQfn9bmVkMtVenqZW1M5KWSdxjEU/kGY4IzJTh2bnDgzG2zhmc7tU1IgylK541lbz kPaKeRAbjsgPHHX73QRGX2LEOrcx5thv+9aT0gHhE/5vD+uDrspDyntbp9JeKp9+bqBz Nmng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date:dkim-signature; bh=UxO4lwP1Y614pYP6ZHT+U53NlXgl8rz0sajx/aIIUBo=; fh=mM5M8T4DXV8DJNPUiyLhDfaq1mOfPBKiI80wpXFrPvU=; b=Hx76EulKQiQwoA109/NFm7HdAlaUTNnvBU7Z7BelPemZLMsqIlW+FHuZxOGVZXrzAW ca69GXzZk//G2IA6mk8mrwKAwxkOsvdPxyX22BI581N4KbKKCuUTMo5/ciUDD738dkb6 aVj/h7fqIIV7yaFJkMDA+Unvo5h7RruFhlJTFWvh0uglLERFHt76gHO0QSvM8QqYTQZY 6rT62SOe6sWOgU/ay3Okd47yQ4DJnR+kS8VaQC1+acpCNk02+pFwlivYpf6QbU7q7zTm xpub0fZX9tIsUUA/TfWQEJI2UQYx00g1oyEKSOBBxyV7U8gEU5aXJHU9GtNbNUZThelU AoXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b="n/6iq4hd"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id bs123-20020a632881000000b005c21d7ee51asi5459969pgb.301.2023.12.13.15.57.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Dec 2023 15:57:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b="n/6iq4hd"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id EAD648072157; Wed, 13 Dec 2023 15:56:37 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230050AbjLMX41 (ORCPT + 99 others); Wed, 13 Dec 2023 18:56:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229725AbjLMX4Z (ORCPT ); Wed, 13 Dec 2023 18:56:25 -0500 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EAF659C for ; Wed, 13 Dec 2023 15:56:31 -0800 (PST) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-5e2fc8fe1a8so590947b3.1 for ; Wed, 13 Dec 2023 15:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1702511791; x=1703116591; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=UxO4lwP1Y614pYP6ZHT+U53NlXgl8rz0sajx/aIIUBo=; b=n/6iq4hdeY0NUcjf+rU2vxu/hbxPQEwPdMuv5fe1m2M/1AIqqTyOJb8jIZ2isBMKhH Zxn1J7+IgX/rx0FUVBfu92Rq59km+IIVm+tlw1sKYJ8uqF18t8RUxIb+XQ6lNFeBqFEu 5T7AC13pb1a9Hkqc6MuuKsunBAWcdhLoC6eEcZ7QMkSr4huW5y4Vvu7lOrA3fBYbFwrD bYElGiuFVWvZSxZ+1y8Pm+cUVZW9zmCQ1Xk9nhkTNlr5+Qh+eWwFfPjK66utuJUy7C3E pscjJ2hH4aawF6azeH6eBKbcM+y3zl/GCnbntJOv6RvpBd88QWii3BCR3Z3yta68S4c/ QBNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702511791; x=1703116591; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=UxO4lwP1Y614pYP6ZHT+U53NlXgl8rz0sajx/aIIUBo=; b=Bg6/Er7h7uHMnNo9nra+ZpnYeA3a7gImpulMpSqxkGXbezu71435iMeEiYvpa/mpNg P6iXSKWOUxWkAiWWAAqQ5QuhvC+0fVqG4RR8z47rM4ZojYAq11uRPISAQAEVPaAsVPiK yC+uI6CB4MnM4Fs/QK5IyiN+oCPG0MGxhq+dcupulFSZmhOJSGo4l0wL68qkzfspLB6c 5+K6gXD7XbYH75iie8N8gC2/5tKygHld0TEsQ8BglIoOZZivc8OKzKDU3HL4HiiDhNir Q34Fv7E+YiVBPeJk8cFA6DBt0rijeZY1UFX41ljF4cwdSvxKUKpMoxw8/dJlljtE4QWW Hfxw== X-Gm-Message-State: AOJu0YyDxX1VX+SluGE9lMrAlC3OwtHWksYLWABBS4KMiou01VvSlsnp RmO+hyOFFB401GqJJoW3VYmPMnb7cbg= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:14d:b0:db5:3aaf:5207 with SMTP id p13-20020a056902014d00b00db53aaf5207mr151250ybh.3.1702511791190; Wed, 13 Dec 2023 15:56:31 -0800 (PST) Date: Wed, 13 Dec 2023 15:56:29 -0800 In-Reply-To: <06076290-4efb-5d71-74eb-396d325447e0@loongson.cn> Mime-Version: 1.0 References: <20231130111804.2227570-1-zhaotianrui@loongson.cn> <20231130111804.2227570-2-zhaotianrui@loongson.cn> <023b6f8f-301b-a6d0-448b-09a602ba1141@loongson.cn> <06076290-4efb-5d71-74eb-396d325447e0@loongson.cn> Message-ID: Subject: Re: [PATCH v5 1/4] KVM: selftests: Add KVM selftests header files for LoongArch From: Sean Christopherson To: maobibo Cc: zhaotianrui , Shuah Khan , Paolo Bonzini , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Vishal Annapurve , Huacai Chen , WANG Xuerui , loongarch@lists.linux.dev, Peter Xu , Vipin Sharma , huangpei@loongson.cn Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL 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 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Wed, 13 Dec 2023 15:56:38 -0800 (PST) On Wed, Dec 13, 2023, maobibo wrote: >=20 > On 2023/12/13 =E4=B8=8B=E5=8D=883:15, zhaotianrui wrote: > >=20 > > =E5=9C=A8 2023/12/13 =E4=B8=8A=E5=8D=881:18, Sean Christopherson =E5=86= =99=E9=81=93: > > > On Tue, Dec 12, 2023, zhaotianrui wrote: > > > > Hi, Sean: > > > >=20 > > > > I want to change the definition of=C2=A0 DEFAULT_GUEST_TEST_MEM in = the common > > > > file "memstress.h", like this: > > > >=20 > > > > =C2=A0 /* Default guest test virtual memory offset */ > > > > +#ifndef DEFAULT_GUEST_TEST_MEM > > > > =C2=A0 #define DEFAULT_GUEST_TEST_MEM=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 0xc0000000 > > > > +#endif > > > >=20 > > > > As this address should be re-defined in LoongArch headers. > > >=20 > > > Why?=C2=A0 E.g. is 0xc0000000 unconditionally reserved, not guarantee= d to > > > be valid, > > > something else? > > >=20 > > > > So, do you have any suggesstion? > > >=20 > > > Hmm, I think ideally kvm_util_base.h would define a range of memory t= hat > > > can be used by tests for arbitrary data.=C2=A0 Multiple tests use 0xc= 0000000, > > > which is not entirely arbitrary, i.e. it doesn't _need_ to be 0xc0000= 000, > > > but 0xc0000000 is convenient because it's 32-bit addressable and does= n't > > > overlap reserved areas in other architectures. > In general text entry address of user application on x86/arm64 Linux > is 0x200000, however on LoongArch system text entry address is strange, i= ts > value 0x120000000. >=20 > When DEFAULT_GUEST_TEST_MEM is defined as 0xc0000000, there is limitation > for guest memory size, it cannot exceed 0x120000000 - 0xc000000 =3D 1.5G > bytes, else there will be conflict. However there is no such issue on > x86/arm64, since 0xc0000000 is above text entry address 0x200000. Ugh, I spent a good 30 minutes trying to figure out how any of this works o= n x86 before I realized DEFAULT_GUEST_TEST_MEM is used for the guest _virtual_ ad= dress space. I was thinking we were talking about guest _physical_ address, hence my com= ments about it being 32-bit addressable and not overlappin reserved areas. E.g. = on x86, anything remotely resembling a real system has regular memory, a.k.a. DRAM,= split between low memory (below the 32-bit boundary, i.e. below 4GiB) and high me= mory (from 4GiB to the max legal physical address). Addresses above "top of low= er usable DRAM" (TOLUD) are reserved (again, in a "real" system) for things li= ke PCI, local APIC, I/O APIC, and the _architecturally_ defined RESET vector. I couldn't figure out how x86 worked, because KVM creates an KVM-internal m= emslot at address 0xfee00000. And then I realized the test creates memslots at co= mpletely different GPAs, and DEFAULT_GUEST_TEST_MEM is used only as super arbitrary guest virtual address. *sigh* Anyways... > The LoongArch link scripts actually is strange, it brings out some > compatible issues such dpdk/kvm selftest when user applications > want fixed virtual address space. Can you elaborate on compatiblity issues? I don't see the connection betwe= en DPDK and KVM selftests. > So here DEFAULT_GUEST_TEST_MEM is defined as 0x130000000 separately, mayb= e > 0x140000000 is better since it is 1G super-page aligned for 4K page size. I would strongly prefer we carve out a virtual address range that *all* tes= ts can safely use for test-specific code and data. E.g. if/when we add usersp= ace support to selftests, I like the idea of having dedicated address spaces fo= r kernel vs. user[*]. Maybe we can march in that generally direction and define test's virtual ad= dress range to be in kernel space, i.e. the high half. I assume/hope that would = play nice with all architectures' entry points? [*] https://lore.kernel.org/all/20231102155111.28821-1-guang.zeng@intel.com