On Wed, Dec 13, 2023, maobibo wrote: > > On 2023/12/13 下午3:15, zhaotianrui wrote: > > > > 在 2023/12/13 上午1:18, Sean Christopherson 写道: > > > On Tue, Dec 12, 2023, zhaotianrui wrote: > > > > Hi, Sean: > > > > > > > > I want to change the definition of DEFAULT_GUEST_TEST_MEM in the common > > > > file "memstress.h", like this: > > > > > > > > /* Default guest test virtual memory offset */ > > > > +#ifndef DEFAULT_GUEST_TEST_MEM > > > > #define DEFAULT_GUEST_TEST_MEM 0xc0000000 > > > > +#endif > > > > > > > > As this address should be re-defined in LoongArch headers. > > > > > > Why? E.g. is 0xc0000000 unconditionally reserved, not guaranteed to > > > be valid, > > > something else? > > > > > > > So, do you have any suggesstion? > > > > > > Hmm, I think ideally kvm_util_base.h would define a range of memory that > > > can be used by tests for arbitrary data. Multiple tests use 0xc0000000, > > > which is not entirely arbitrary, i.e. it doesn't _need_ to be 0xc0000000, > > > but 0xc0000000 is convenient because it's 32-bit addressable and doesn'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, its > value 0x120000000. > > When DEFAULT_GUEST_TEST_MEM is defined as 0xc0000000, there is limitation > for guest memory size, it cannot exceed 0x120000000 - 0xc000000 = 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 on x86 before I realized DEFAULT_GUEST_TEST_MEM is used for the guest _virtual_ address space. I was thinking we were talking about guest _physical_ address, hence my comments 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 memory (from 4GiB to the max legal physical address). Addresses above "top of lower usable DRAM" (TOLUD) are reserved (again, in a "real" system) for things like 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 memslot at address 0xfee00000. And then I realized the test creates memslots at completely 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 between DPDK and KVM selftests. > So here DEFAULT_GUEST_TEST_MEM is defined as 0x130000000 separately, maybe > 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* tests can safely use for test-specific code and data. E.g. if/when we add userspace support to selftests, I like the idea of having dedicated address spaces for kernel vs. user[*]. Maybe we can march in that generally direction and define test's virtual address 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@xxxxxxxxx
