From: SeongJae Park <sj@kernel.org>
To: Benjamin Berg <benjamin@sipsolutions.net>
Cc: SeongJae Park <sj@kernel.org>,
linux-um@lists.infradead.org, johannes@sipsolutions.net,
Benjamin Berg <benjamin.berg@intel.com>
Subject: Re: [PATCH v5] um: switch to regset API and depend on XSTATE
Date: Mon, 2 Dec 2024 23:02:18 -0800 [thread overview]
Message-ID: <20241203070218.240797-1-sj@kernel.org> (raw)
In-Reply-To: <20241023094120.4083426-1-benjamin@sipsolutions.net>
Hello,
On Wed, 23 Oct 2024 11:41:20 +0200 Benjamin Berg <benjamin@sipsolutions.net> wrote:
> From: Benjamin Berg <benjamin.berg@intel.com>
>
> The PTRACE_GETREGSET API has now existed since Linux 2.6.33. The XSAVE
> CPU feature should also be sufficiently common to be able to rely on it.
>
> With this, define our internal FP state to be the hosts XSAVE data. Add
> discovery for the hosts XSAVE size and place the FP registers at the end
> of task_struct so that we can adjust the size at runtime.
>
> Next we can implement the regset API on top and update the signal
> handling as well as ptrace APIs to use them. Also switch coredump
> creation to use the regset API and finally set HAVE_ARCH_TRACEHOOK.
>
> This considerably improves the signal frames. Previously they might not
> have contained all the registers (i386) and also did not have the
> sizes and magic values set to the correct values to permit userspace to
> decode the frame.
>
> As a side effect, this will permit UML to run on hosts with newer CPU
> extensions (such as AMX) that need even more register state.
I just found kunit starts failing from the mainline commit of this patch on my
qemu-x86 Debian system, as below.
$ git checkout 3f17fed2149192c7d3b76a45a6a87b4ff22cd586
$ ./tools/testing/kunit/kunit.py run --kunitconfig mm/damon/tests/ --build_dir ../kunit.out/
[...]
[22:48:27] Configuring KUnit Kernel ...
Regenerating .config ...
Populating config with:
$ make ARCH=um O=../kunit.out/ olddefconfig
[22:48:30] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=../kunit.out/ olddefconfig
Building with:
$ make all compile_commands.json ARCH=um O=../kunit.out/ --jobs=40
[...]
[22:48:46] Starting KUnit Kernel (1/1)...
[22:48:46] ============================================================
Running tests with:
$ ../kunit.out/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
[22:48:46] [ERROR] Test: <missing>: Could not find any KTAP output. Did any KUnit tests run?
[22:48:46] ============================================================
[22:48:46] Testing complete. Ran 0 tests: errors: 1
[22:48:46] Elapsed time: 19.285s total, 3.805s configuring, 15.475s building, 0.006s running
>
> Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
[...]
> -void arch_init_registers(int pid)
> -{
> - struct user_fpxregs_struct fpx_regs;
> - int err;
> -
> - err = ptrace(PTRACE_GETFPXREGS, pid, 0, &fpx_regs);
> - if (!err)
> - return;
> -
> - if (errno != EIO)
> - panic("check_ptrace : PTRACE_GETFPXREGS failed, errno = %d",
> - errno);
> -
> - have_fpx_regs = 0;
> -}
> -#else
> -
> -int get_fp_registers(int pid, unsigned long *regs)
> +int arch_init_registers(int pid)
> {
> - return save_fp_registers(pid, regs);
> + struct iovec iov = {
> + /* Just use plenty of space, it does not cost us anything */
> + .iov_len = 2 * 1024 * 1024,
> + };
> + int ret;
> +
> + iov.iov_base = mmap(NULL, iov.iov_len, PROT_WRITE | PROT_READ,
> + MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
> + if (iov.iov_base == MAP_FAILED)
> + return -ENOMEM;
> +
> + /* GDB has x86_xsave_length, which uses x86_cpuid_count */
> + ret = ptrace(PTRACE_GETREGSET, pid, NT_X86_XSTATE, &iov);
> + if (ret)
> + ret = -errno;
> + munmap(iov.iov_base, 2 * 1024 * 1024);
> +
> + host_fp_size = iov.iov_len;
> +
> + return ret;
> }
And seems it fails from the registers initialization step:
$ ../kunit.out/linux
Core dump limits :
soft - 0
hard - NONE
Checking that ptrace can change system call numbers...OK
Checking syscall emulation for ptrace...OK
Checking environment variables for a tempdir...none found
Checking if /dev/shm is on tmpfs...OK
Checking PROT_EXEC mmap in /dev/shm...OK
Failed to initialize default registers
I'm not familiar with uml code, so reporting this issue first. Any thought, please?
Thanks,
SJ
[...]
next prev parent reply other threads:[~2024-12-03 7:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-23 9:41 [PATCH v5] um: switch to regset API and depend on XSTATE Benjamin Berg
2024-12-03 7:02 ` SeongJae Park [this message]
2024-12-03 8:40 ` Benjamin Berg
2024-12-03 15:00 ` SeongJae Park
2024-12-03 15:56 ` SeongJae Park
2024-12-03 17:07 ` Benjamin Berg
2024-12-03 21:55 ` SeongJae Park
2024-12-13 20:00 ` Brian Norris
2024-12-13 23:08 ` Benjamin Berg
2024-12-14 12:25 ` Benjamin Berg
2024-12-16 20:06 ` Brian Norris
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=20241203070218.240797-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=benjamin.berg@intel.com \
--cc=benjamin@sipsolutions.net \
--cc=johannes@sipsolutions.net \
--cc=linux-um@lists.infradead.org \
/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.