linux-um archives
 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 13:55:06 -0800	[thread overview]
Message-ID: <20241203215506.5082-1-sj@kernel.org> (raw)
In-Reply-To: <57281ae15f35f1b7ec5b898d12de44c96827cb27.camel@sipsolutions.net>

On Tue, 03 Dec 2024 18:07:36 +0100 Benjamin Berg <benjamin@sipsolutions.net> wrote:

> On Tue, 2024-12-03 at 07:56 -0800, SeongJae Park wrote:
> > On Tue, 03 Dec 2024 07:01:09 SeongJae Park <sj@kernel.org> wrote:
> > 
> > > 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.
> > 
> > Oh, and seems my qemu has some downstream changes.  I will try to reproduce the
> > issue with upstream versions and report the result again.
> 
> I doubt that is the reason. The code tries to detect the size of the
> NT_X86_XSTATE register set and something breaks.
> 
> Thinking about it a bit, the only good explanation is that the qemu CPU
> does not have XSTATE support. This would cause the ptrace syscall to
> fetch the NT_X86_XSTATE register set to always fail (with -ENODEV).
> 
> Honestly, I just had not expected such an issue. Could you try the
> below patch to add a fallback?

Thank you, I just confiremd it fixes my issue.

Tested-by: SeongJae Park <sj@kernel.org>


Thanks,
SJ

[...]


  reply	other threads:[~2024-12-03 21:55 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
2024-12-03 15:56       ` SeongJae Park
2024-12-03 17:07         ` Benjamin Berg
2024-12-03 21:55           ` SeongJae Park [this message]
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=20241203215506.5082-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox