Missing cache information on x86-64 under Intel TDX (glibc bug 30643)

This is a continuation of glibc bug 30037, whose root cause was not fixed: Missing cache information on x86-64 under Intel TDX glibc 2.34 and newer segfault if CPUID leaf 0x2 reports zero

Re: GLibC AMD CPUID cache reporting regression (was Re: qemu-user self emulation broken with default CPU on x86/x64)

* Daniel P. Berrangé: > On Mon, Jul 03, 2023 at 06:03:08PM +0200, Pierrick Bouvier wrote: >> Hi everyone, >> >> Recently (in d135f781 [1], between v7.0.0 and v8.0.0), qemu-user default cpu >> was updated to "max" instead of qemu32/qemu64. >> >> This change "broke" qemu self emulation if this

Re: Use of unshare(CLONE_FS) in virtiofsd

* Vivek Goyal: >> The usual >> recommendation for emulating it is to use openat with O_PATH, and then >> use getxattr on the virtual /proc/self/fd path. This needs an >> additional system call (openat, getxattr, close instead of fchdir, >> getxattr), > > openat(O_PATH) + getxattr(/proc/self/fd)

Use of unshare(CLONE_FS) in virtiofsd

I've got a proposed extension for glibc's pthread_create which allows the creation of threads with a dedicated current working directory/umask/chroot: [PATCH 0/2] Introduce per-thread file system properties on Linux I

Re: [PATCH for 7.1] linux-user: fix compat with glibc >= 2.36 sys/mount.h

* Daniel P. Berrangé: > CC'ing Florian to get the POV of a glibc maintainer on what we've > had to do to work around this compatibility brekage. Meh, that's really not great. 8-( I'll see if I can add a similar workaround to the glibc headers. Unfortunately I'm busy with other stuff right now,

Re: Emulating CPUs with larger atomic accesses

* Richard Henderson: > On 5/24/22 02:27, Florian Weimer wrote: >> * Richard Henderson: >> >>> On 5/13/22 03:00, Florian Weimer wrote: >>>> What's QEMU's approach to emulating CPU instructions that atomatically >>>> operate on values larger than

Re: Emulating CPUs with larger atomic accesses

* Richard Henderson: > On 5/13/22 03:00, Florian Weimer wrote: >> What's QEMU's approach to emulating CPU instructions that atomatically >> operate on values larger than what is supported by the host CPU? >> I assume that for full system emulation, this is not a prob

Emulating CPUs with larger atomic accesses

What's QEMU's approach to emulating CPU instructions that atomatically operate on values larger than what is supported by the host CPU? I assume that for full system emulation, this is not a problem, but qemu-user will not achieve atomic behavior on shared memory mappings. How much of a problem

Re: Portable inline asm to get address of TLS variable

* Stefan Hajnoczi: > On Tue, Mar 01, 2022 at 12:54:49PM +0100, Florian Weimer wrote: >> > I took a quick look at C++20 coroutines since they are available in >> > compilers but the primitives look hard to use even from C++, let alone >> > from C. >> >>

Re: How to backtrace an separate stack?

* Tom Tromey: > Florian> I'm a bit surprised by this. Conceptually, why would GDB need to > know > Florian> about stack boundaries? Is there some heuristic to detect broken > Florian> frames? > > Yes, the infamous "previous frame inner to this frame" error message. I > think this is primarily

Re: How to backtrace an separate stack?

* Stefan Hajnoczi via Gdb: > The QEMU emulator uses coroutines with separate stacks. It can be > challenging to debug coroutines that have yielded because GDB is not > aware of them (no thread is currently executing them). > > QEMU has a GDB Python script that helps. It "creates" a stack frame

Re: Portable inline asm to get address of TLS variable

* Stefan Hajnoczi: >> But going against ABI and toolchain in this way is really no long-term >> solution. You need to switch to stackless co-routines, or we need to >> provide proper ABI-level support for this. Today it's the thread >> pointer, tomorrow it's the shadow stack pointer, and the

Re: Portable inline asm to get address of TLS variable

* Stefan Hajnoczi: > I'm basically asking whether the _var input operand is treated as > volatile and part of the inline assembly or whether it's just regular > C code that the compiler may optimize with the surrounding function? _var is evaluated outside of the inline assembly, any compiler

Re: Portable inline asm to get address of TLS variable

* Stefan Hajnoczi: > On Wed, 16 Feb 2022 at 18:14, Florian Weimer wrote: >> >> * Stefan Hajnoczi: >> >> > I've been trying to make the inline asm that gets the address of a TLS >> > variable for QEMU coroutines pass QEMU's GitLab CI. >> > https://g

Re: Portable inline asm to get address of TLS variable

* Stefan Hajnoczi: > I've been trying to make the inline asm that gets the address of a TLS > variable for QEMU coroutines pass QEMU's GitLab CI. > https://gitlab.com/stefanha/qemu/-/blob/coroutine-tls-fix/include/qemu/coroutine-tls.h#L89 > > The code isn't -fPIC-friendly (R_X86_64_TPOFF32

Re: [RFC v2 1/4] tls: add macros for coroutine-safe TLS variables

* Peter Maydell: > On Thu, 2 Dec 2021 at 14:44, Peter Maydell wrote: >> My compiler-developer colleagues present the following case where >> 'noinline' is not sufficient for the compiler to definitely >> use different values of the address-of-the-TLS-var across an >> intervening function call:

Re: [RFC v2 1/4] tls: add macros for coroutine-safe TLS variables

* Stefan Hajnoczi: > +#elif defined(__x86_64__) > +#define QEMU_CO_TLS_ADDR(ret, var) \ > +asm volatile("rdfsbase %0\n\t" \ > + "lea "#var"@tpoff(%0), %0" : "=r"(ret)) > +#endif RDFSBASE needs quite recent kernels. I

Disabling TLS address caching to help QEMU on GNU/Linux

Currently, the GNU/Linux ABI does not really specify whether the thread pointer (the address of the TCB) may change at a function boundary. Traditionally, GCC assumes that the ABI allows caching addresses of thread-local variables across function calls. Such caching varies in aggressiveness

Re: [PATCH RFC 1/4] docs: add a table showing x86-64 ABI compatibility levels

* Peter Maydell: > Apart from the QEMU/KVM specific CPU models, why is this something > we should be documenting rather than, say, the people specifying > what the ABI compatiblity levels are ? The psABI only cares about userspace, and the specification there deliberately excludes CPU features

Re: [PATCH RFC 1/4] docs: add a table showing x86-64 ABI compatibility levels

* Daniel P. Berrangé: > and supported by GCC, CLang, GLibC and more. Clang and glibc are the official spellings, I think. > diff --git a/docs/system/cpu-models-x86-abi.csv > b/docs/system/cpu-models-x86-abi.csv > new file mode 100644 > index 00..4565e6a535 > --- /dev/null > +++

Re: [PATCH] fcntl: Add 32bit filesystem mode

* Peter Maydell: > We open fd 3 to read '.'; we issue the new fcntl, which > succeeds. Then there's some unrelated stuff operating on > stdout. Then we do a getdents64(), but the d_off values > we get back are still 64 bits. The guest binary doesn't > like those, so it fails. My expectation was

Re: [PATCH] ext4: Give 32bit personalities 32bit hashes

* Linus Walleij: > It was brought to my attention that this bug from 2018 was > still unresolved: 32 bit emulators like QEMU were given > 64 bit hashes when running 32 bit emulation on 64 bit systems. > > The personality(2) system call supports to let processes > indicate that they are 32 bit

Re: [PATCH v2 051/109] virtiofsd: add seccomp whitelist

* David Alan Gilbert: > * Florian Weimer (fwei...@redhat.com) wrote: >> * David Alan Gilbert: >> >> > +static const int syscall_whitelist[] = { >> > +/* TODO ireg sem*() syscalls */ >> > +SCMP_SYS(brk), >> > +SCMP_SYS(capg

Re: [PATCH v2 051/109] virtiofsd: add seccomp whitelist

* David Alan Gilbert: > +static const int syscall_whitelist[] = { > +/* TODO ireg sem*() syscalls */ > +SCMP_SYS(brk), > +SCMP_SYS(capget), /* For CAP_FSETID */ > +SCMP_SYS(capset), > +SCMP_SYS(clock_gettime), > +SCMP_SYS(gettimeofday), Is this to suppose to work on

Re: [Qemu-devel] [PATCH 3/7] configure: add CET support

* Paolo Bonzini: > Actually I might change it to cf-protection, since that's what the GCC > flag is named. The GCC flag is supposed to generic, so that it can be used for similar features other architectures might provide. Your code looks rather x86-centric to me, so CET seems appropriate here.

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

* Adhemerval Zanella: > On 27/12/2018 16:09, Florian Weimer wrote: >> * Adhemerval Zanella: >> >>> Also for glibc standpoint, although reverting it back to use getdents >>> syscall for non-LFS mode might fix this issue for architectures that >>>

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

* Florian Weimer: > * Adhemerval Zanella: > >> On 27/12/2018 16:09, Florian Weimer wrote: >>> * Adhemerval Zanella: >>> >>>> Also for glibc standpoint, although reverting it back to use getdents >>>> syscall for non-LFS mode might fix t

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

* Dmitry V. Levin: > On Thu, Dec 27, 2018 at 06:18:19PM +0100, Florian Weimer wrote: >> We have a bit of an interesting problem with respect to the d_off >> field in struct dirent. >> >> When running a 64-bit kernel on certain file systems, notably ext4, >> this

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

* Adhemerval Zanella: > Also for glibc standpoint, although reverting it back to use getdents > syscall for non-LFS mode might fix this issue for architectures that > provides non-LFS getdents syscall it won't be a fix for architectures > that still provides off_t different than off64_t *and*

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

* Andy Lutomirski: >> On Dec 27, 2018, at 10:18 AM, Florian Weimer wrote: >> >> We have a bit of an interesting problem with respect to the d_off >> field in struct dirent. >> >> When running a 64-bit kernel on certain file systems, notably ext4, >

[Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

We have a bit of an interesting problem with respect to the d_off field in struct dirent. When running a 64-bit kernel on certain file systems, notably ext4, this field uses the full 63 bits even for small directories (strace -v output, wrapped here for readability): getdents(3, [

Re: [Qemu-devel] /usr/bin/m4: internal error detected

On 12/01/2017 10:51 AM, John Paul Adrian Glaubitz wrote: Hi Daniel! On 12/01/2017 06:08 AM, Daniel Kahn Gillmor wrote: Copying file po/Makefile.in.in Copying file po/Makevars.template qemu: Unsupported syscall: -1 m4: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion

Re: [Qemu-devel] /usr/bin/m4: internal error detected

On 12/01/2017 12:58 PM, John Paul Adrian Glaubitz wrote: The fix is already in the packaging source of Debian's glibc [1] after I reported the bug. But the updated package has not been uploaded to the FTP servers yet. I'll ask Debian's glibc maintainers to push it. Okay. Based on the other

Re: [Qemu-devel] [PATCH] memfd: fix configure test

On 11/28/2017 12:42 PM, Marc-André Lureau wrote: Couldn't the declarations be put in sys/memfd.h like the man claimed it would be for > 1y? We discussed it. It was a typo in the manual page. There never was a header file: https://marc.info/?l=linux-man=150988359906012=2 The UAPI

[Qemu-devel] i386: SSE 4 implementation does not match bare metal

We received a bug report that the SSE-4.2-based strstr in glibc 2.17 was misbehaving and returned NULL for certain inputs, even though the search pattern is clearly present in the subject string. I'm attaching a test case. You can run it as "./tst-strstr 3" to directly go to one failing case.

Re: [Qemu-devel] spec, RFC: TLS support for NBD

before proceeding. I cannot comment on whether the proposed STARTTLS command is at the correct stage of the NBD protocol. If there is a protocol description for NBD, I can have a look. -- Florian Weimer / Red Hat Product Security