linux-kernel - Re: [PATCH v5 1/4] KVM: selftests: Add KVM selftests header files for LoongArch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZXpErTHBn6HeQUOp@google.com>
Date:   Wed, 13 Dec 2023 15:56:29 -0800
From:   Sean Christopherson <seanjc@...gle.com>
To:     maobibo <maobibo@...ngson.cn>
Cc:     zhaotianrui <zhaotianrui@...ngson.cn>,
        Shuah Khan <shuah@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        Vishal Annapurve <vannapurve@...gle.com>,
        Huacai Chen <chenhuacai@...nel.org>,
        WANG Xuerui <kernel@...0n.name>, loongarch@...ts.linux.dev,
        Peter Xu <peterx@...hat.com>,
        Vipin Sharma <vipinsh@...gle.com>, huangpei@...ngson.cn
Subject: Re: [PATCH v5 1/4] KVM: selftests: Add KVM selftests header files for LoongArch

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@intel.com