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 new

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 expe

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, s

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 la

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 pro

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 is

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 for

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 day

Re: Portable inline asm to get address of TLS variable

* Stefan Hajnoczi: > I'm basically asking whether the &tls_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? &tls_var is evaluated outside of the inline assembly, any compi

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. >> >

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 relocat

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 t

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 betwe

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 us

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 > +++ b/docs/s

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 th

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 Linu

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 32-bi

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 >>> provi

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* on

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, [ {d_ino=149430

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 `e

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 res

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&m=150988359906012&w=2 The UAPI h

[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. I'

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

handshake 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