All of lore.kernel.org
 help / color / mirror / Atom feed
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
Subject: Re: [PATCH v5] um: switch to regset API and depend on XSTATE
Date: Tue,  3 Dec 2024 07:00:20 -0800	[thread overview]
Message-ID: <20241203150021.981-1-sj@kernel.org> (raw)
In-Reply-To: <029ad08a1aa2dc512b442c988d0edebdd7aef4b0.camel@sipsolutions.net>

On Tue, 03 Dec 2024 09:40:34 +0100 Benjamin Berg <benjamin@sipsolutions.net> wrote:

> Hi,
> 
> that probably means the size detection for the FPU state (i.e.
> PTRACE_GETREGSET for NT_X86_XSTATE is incorrect on a 32bit host in some
> way.
> 
> Is there anything special about the qemu setup or it is just a default
> qemu-x86?

I use default qemu-system-x86_64 on my system.

    $ qemu-system-x86_64 --version
    QEMU emulator version 8.2.2 (qemu-8.2.2-1.1.hs+fb.el9)
    Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers

I forgot saying it is not just x86 but x86_64, sorry.


Thanks,
SJ

> 
> Benjamin
> 
> On Mon, 2024-12-02 at 23:02 -0800, SeongJae Park wrote:
> > 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
> > 
> > [...]
> > 
> 
> 
> 


  reply	other threads:[~2024-12-03 15:00 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
2024-12-03  8:40   ` Benjamin Berg
2024-12-03 15:00     ` SeongJae Park [this message]
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=20241203150021.981-1-sj@kernel.org \
    --to=sj@kernel.org \
    --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.