[PATCH v2 RESEND] target/ppc/arch_dump: set prstatus pid to cpuid

Every other architecture does this, and debuggers need it to be able to identify which prstatus note corresponds to which CPU. Reviewed-by: Thomas Huth Reviewed-by: Harsh Prateek Bora Signed-off-by: Omar Sandoval --- Resend of [1]. No changes other than adding Thomas's Reviewed-by. Thanks

Re: [PATCH v2] target/ppc/arch_dump: set prstatus pid to cpuid

On Mon, Jul 01, 2024 at 09:51:35AM -0700, Omar Sandoval wrote: > Every other architecture does this, and debuggers need it to be able to > identify which prstatus note corresponds to which CPU. > > Reviewed-by: Harsh Prateek Bora Oops, I forgot to copy Thomas's reviewed-by from v

[PATCH v2] target/ppc/arch_dump: set prstatus pid to cpuid

Every other architecture does this, and debuggers need it to be able to identify which prstatus note corresponds to which CPU. Reviewed-by: Harsh Prateek Bora Signed-off-by: Omar Sandoval --- This is v2 from my small series [1] making QEMU fill the pr_pid field of the NT_PRSTATUS note

[PATCH 2/2] target/ppc/arch_dump: set prstatus pid to cpuid

Every other architecture does this, and debuggers need it to be able to identify which prstatus note corresponds to which CPU. Signed-off-by: Omar Sandoval --- target/ppc/arch_dump.c | 21 - 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/target/ppc

[PATCH 1/2] target/s390x/arch_dump: use correct byte order for pid

The pid field of prstatus needs to be big endian like all of the other fields. Fixes: f738f296eaae ("s390x/arch_dump: pass cpuid into notes sections") Signed-off-by: Omar Sandoval --- target/s390x/arch_dump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ta

[PATCH 0/2] arch_dump: fix prstatus pid on s390x and ppc

. There are two exceptions: on s390x, there's an endianness bug (it's not byte swapped if the host is little endian), and on ppc, it's not set at all (it defaults to zero). They're both easy fixes. Thanks, Omar 1: https://github.com/osandov/drgn 2: https://github.com/osandov/drgn/issues/404 Omar

Re: [PATCH qemu 2/2] dump: Only use the makedumpfile flattened format when necessary

On Tue, Sep 12, 2023 at 10:34:04AM +0400, Marc-André Lureau wrote: > Hi > > On Wed, Aug 23, 2023 at 2:03 PM Marc-André Lureau > wrote: > > > > Hi > > > > On Wed, Aug 23, 2023 at 4:31 AM Stephen Brennan > > wrote: > > > > > > Stephen Brennan writes: > > > > Marc-André Lureau writes: > > > >> I

[PATCH v2] 9pfs: local: ignore O_NOATIME if we don't have permissions

From: Omar Sandoval QEMU's local 9pfs server passes through O_NOATIME from the client. If the QEMU process doesn't have permissions to use O_NOATIME (namely, it does not own the file nor have the CAP_FOWNER capability), the open will fail. This causes issues when from the client's point of view

Re: [PATCH] 9pfs: local: ignore O_NOATIME if we don't have permissions

On Fri, Apr 17, 2020 at 12:45:36PM +0200, Christian Schoenebeck wrote: > On Donnerstag, 16. April 2020 20:47:11 CEST Omar Sandoval wrote: > > > > Luckily, O_NOATIME is effectively a hint, and is often ignored by, e.g., > > > > network filesystems. open(2) notes that O_NO

Re: [PATCH] 9pfs: local: ignore O_NOATIME if we don't have permissions

On Thu, Apr 16, 2020 at 04:58:31PM +0200, Christian Schoenebeck wrote: > On Donnerstag, 16. April 2020 02:44:33 CEST Omar Sandoval wrote: > > From: Omar Sandoval > > > > QEMU's local 9pfs server passes through O_NOATIME from the client. If > > the QEMU process does

[PATCH] 9pfs: local: ignore O_NOATIME if we don't have permissions

From: Omar Sandoval QEMU's local 9pfs server passes through O_NOATIME from the client. If the QEMU process doesn't have permissions to use O_NOATIME (namely, it does not own the file nor have the CAP_FOWNER capability), the open will fail. This causes issues when from the client's point of view