All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: maobibo <maobibo@loongson.cn>
Cc: zhaotianrui <zhaotianrui@loongson.cn>,
	Shuah Khan <shuah@kernel.org>,
	 Paolo Bonzini <pbonzini@redhat.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	 Vishal Annapurve <vannapurve@google.com>,
	Huacai Chen <chenhuacai@kernel.org>,
	 WANG Xuerui <kernel@xen0n.name>,
	loongarch@lists.linux.dev, Peter Xu <peterx@redhat.com>,
	 Vipin Sharma <vipinsh@google.com>,
	huangpei@loongson.cn
Subject: Re: [PATCH v5 1/4] KVM: selftests: Add KVM selftests header files for LoongArch
Date: Wed, 13 Dec 2023 15:56:29 -0800	[thread overview]
Message-ID: <ZXpErTHBn6HeQUOp@google.com> (raw)
In-Reply-To: <06076290-4efb-5d71-74eb-396d325447e0@loongson.cn>

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

  reply	other threads:[~2023-12-13 23:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-30 11:18 [PATCH v5 0/4] KVM: selftests: Add LoongArch support Tianrui Zhao
2023-11-30 11:18 ` [PATCH v5 1/4] KVM: selftests: Add KVM selftests header files for LoongArch Tianrui Zhao
2023-12-12  3:08   ` zhaotianrui
2023-12-12 17:18     ` Sean Christopherson
2023-12-13  7:15       ` zhaotianrui
2023-12-13  7:42         ` maobibo
2023-12-13 23:56           ` Sean Christopherson [this message]
2023-12-14  2:20             ` maobibo
2023-11-30 11:18 ` [PATCH v5 2/4] KVM: selftests: Add core KVM selftests support " Tianrui Zhao
2023-12-04  2:05   ` maobibo
2023-11-30 11:18 ` [PATCH v5 3/4] KVM: selftests: Add ucall test " Tianrui Zhao
2023-12-04  2:05   ` maobibo
2023-11-30 11:18 ` [PATCH v5 4/4] KVM: selftests: Add test cases " Tianrui Zhao
2023-12-04  2:11   ` maobibo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZXpErTHBn6HeQUOp@google.com \
    --to=seanjc@google.com \
    --cc=chenhuacai@kernel.org \
    --cc=huangpei@loongson.cn \
    --cc=kernel@xen0n.name \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loongarch@lists.linux.dev \
    --cc=maobibo@loongson.cn \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=shuah@kernel.org \
    --cc=vannapurve@google.com \
    --cc=vipinsh@google.com \
    --cc=zhaotianrui@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.