linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Willy Tarreau <w@1wt.eu>,
	valentin.schneider@arm.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/9] tools/nolibc: fix build issues on aarch64 after unistd cleanup
Date: Fri, 22 Jan 2021 07:42:41 -0800	[thread overview]
Message-ID: <20210122154241.GH2743@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <20210122122542.GA31304@C02TD0UTHF1T.local>

On Fri, Jan 22, 2021 at 12:25:42PM +0000, Mark Rutland wrote:
> On Fri, Jan 22, 2021 at 04:03:26AM -0800, Paul E. McKenney wrote:
> > On Thu, Jan 21, 2021 at 11:11:17AM +0000, Mark Rutland wrote:
> > 
> > [ . . . ]
> > 
> > > I've given this a spin atop v5.11-rc4, building natively on arm64 on a
> > > Debian 10.7 system, and with the whole series applied I'm able to run
> > > the rcutorture kvm.sh script without issue (the CONFIG warnings are
> > > unrelated to nolibc):
> > > 
> > > | [mark@gravadlaks:~/src/linux]% ./tools/testing/selftests/rcutorture/bin/kvm.sh --cpus 255 --configs "TREE03"  --kmake-arg "CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64" --duration 1
> > > | Creating a statically linked C-language initrd
> > > | Done creating a statically linked C-language initrd
> > > | Results directory: /home/mark/src/linux/tools/testing/selftests/rcutorture/res/2021.01.21-10.53.24
> > > | ./tools/testing/selftests/rcutorture/bin/kvm.sh --cpus 255 --configs TREE03 --kmake-arg CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 --duration 1
> > > | ----Start batch 1: Thu 21 Jan 10:53:24 GMT 2021
> > > | TREE03 16: Starting build. Thu 21 Jan 10:53:24 GMT 2021
> > > | TREE03 16: Waiting for build to complete. Thu 21 Jan 10:53:24 GMT 2021
> > > | TREE03 16: Build complete. Thu 21 Jan 10:56:25 GMT 2021
> > > | ---- TREE03 16: Kernel present. Thu 21 Jan 10:56:25 GMT 2021
> > > | ---- Starting kernels. Thu 21 Jan 10:56:25 GMT 2021
> > > | ---- All kernel runs complete. Thu 21 Jan 10:57:35 GMT 2021
> > > | ---- TREE03 16: Build/run results:
> > > |  --- Thu 21 Jan 10:53:24 GMT 2021: Starting build
> > > | :CONFIG_HYPERVISOR_GUEST=y: improperly set
> > > | :CONFIG_KVM_GUEST=y: improperly set
> > 
> > These two (apparently harmless) error messages are due to these lines
> > in CFcommon:
> > 
> > CONFIG_HYPERVISOR_GUEST=y
> > CONFIG_KVM_GUEST=y
> 
> Yup; I had figured this out, but since this wasn't getting in the way of
> actually running the torture tests I had assumed we could deal with that
> at some indefinite point in the future, or simply ignore it. ;)
> 
> > It looks like CONFIG_HYPERVISOR_GUEST is specific to x86, while KVM_GUEST
> > is specific to x86, powerpc, and mips.  (It appears that arm64 doesn't
> > need anything here?) 
> 
> Yup, we don't need any special options -- arm64 doesn't stricly need any
> guest enlightenment to run under a hypervisor, so we never had a need
> for KVM_GUEST or HYPERVISOR_GUEST. We have all the common
> paravritualized drivers (e.g. virtio) in defconfig too, so that should
> all work out of the box.
> 
> > Given this variety, I need to make rcutorture know very early on what
> > arch it is building for.  My current approach of looking at the
> > vmlinux file won't work because I need to get the config right before
> > building the kernel.
> > 
> > One approach would be to look at the initrd/init file, but doing this
> > reliably would mean removing the ability for users to supply their own
> > initrd file trees.  Another approach would be to look at the current
> > environment, perhaps using "uname -m", which will work until someone
> > wants to cross-build.  Yet another approach would be to parse the target
> > line from the output of "${CROSS_COMPILE}gcc -v".
> > 
> > Left to myself, I would parse the output of "${CROSS_COMPILE}gcc -v".
> 
> Heh, I hadn't considered parsing the target line from that output, and I
> guess that works for native builds where "${CROSS_COMPILE}" = "". Neat
> trick!

Credit to Willy Tarreau.  Me, I just realized that he needed to do
-something- to create rcutorture's initrd.  ;-)

> That sounds sensible to me!

Let me see what I can do.

My thought is to add optional CFcommon.<arch> files, and pull them in
when there is a match.  But I will give it more thought.

							Thanx, Paul

      reply	other threads:[~2021-01-22 18:15 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-21  7:20 [PATCH 0/9] tools/nolibc: fix build issues on aarch64 after unistd cleanup Willy Tarreau
2021-01-21  7:20 ` [PATCH 1/9] tools/nolibc: the definition dup() was missing Willy Tarreau
2021-01-21  7:20 ` [PATCH 2/9] tools/nolibc: make dup2() rely on dup3() when available Willy Tarreau
2021-01-21  7:20 ` [PATCH 3/9] tools/nolibc: make getpgrp() fall back to getpgid(0) Willy Tarreau
2021-01-21  7:20 ` [PATCH 4/9] tools/nolibc: implement fork() based on clone() Willy Tarreau
2021-01-21  7:20 ` [PATCH 5/9] tools/nolibc: implement poll() based on ppoll() Willy Tarreau
2021-01-21  7:20 ` [PATCH 6/9] tools/nolibc: get timeval, timespec and timezone from linux/time.h Willy Tarreau
2021-01-21  7:20 ` [PATCH 7/9] tools/nolibc: remove incorrect definitions of __ARCH_WANT_* Willy Tarreau
2021-01-21  7:20 ` [PATCH 8/9] tools/nolibc: emit a detailed error when missing alternate syscall number definitions Willy Tarreau
2021-01-21  7:20 ` [PATCH 9/9] tools/nolibc: fix position of -lgcc in the documented example Willy Tarreau
2021-01-21  7:48 ` [PATCH 10/9] tools/rcutorture: fix position of -lgcc in mkinitrd.sh Willy Tarreau
2021-01-21 11:05 ` [PATCH 0/9] tools/nolibc: fix build issues on aarch64 after unistd cleanup Valentin Schneider
2021-01-21 11:07   ` Willy Tarreau
2021-01-21 11:13   ` Mark Rutland
2021-01-21 11:11 ` Mark Rutland
2021-01-21 14:18   ` Willy Tarreau
2021-01-21 19:54     ` Paul E. McKenney
2021-01-21 20:17       ` Willy Tarreau
2021-01-21 21:36         ` Paul E. McKenney
2021-01-22 12:03   ` Paul E. McKenney
2021-01-22 12:25     ` Mark Rutland
2021-01-22 15:42       ` Paul E. McKenney [this message]

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=20210122154241.GH2743@paulmck-ThinkPad-P72 \
    --to=paulmck@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=valentin.schneider@arm.com \
    --cc=w@1wt.eu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).