From nobody Tue Mar 4 16:46:57 2025 X-Original-To: virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Z6hRT6BDTz5qM8Z for ; Tue, 04 Mar 2025 16:47:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z6hRT2CQDz3bdl for ; Tue, 04 Mar 2025 16:47:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1741106821; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vR6pZ30gVviHwhRnL/cOMtBZ0Ct99MYr3YiiiocJz6M=; b=Qoe2ww+M9WKplkHjS7FxeGIae0HdH/12lpehdjs+AoErH33nz91Ooow+uUevYkX0I+KKjZ YNY1Cgl+mdIXEZSRN3MfJ6bmJAeNRvHBdrHebYsmGScjy+JF9eXNG5oo00w9yl7lX6yZEg VMyzrD90k9zCV+uQTI1H82Nvwald2q9zoPbh1hQ6vSZvM/R6pogdPWl/Hbcv9fKH/IYFSN u8W4jQPHabaFufd1JtBmaaGWx5kPJs73jdBiEKNzFcP03HsqjOmEhOaYiuMWj14x7Ut3M6 4Ak+DI1m7PsPBqYwKCNEGIz7KyYbKmW1XrbFTOR6N5vEbJS6/qGZ/v2klXxBnA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1741106821; a=rsa-sha256; cv=none; b=IzyqkWIgr1CimcXtUxVcuHa0Vc1DwKqE7r2qXHDYqfuSBnoIg2aJrZLmfGTwAgPfQZ0Iwy vpoYuHEeL3T59yn+p9fEfRWAAiak553DJjc5Y05VQ7GfjGA416YZTHHebpkiRedAQHLmWH 1JoMUfra/f2YAlahqzh4+gOwyRYj3xDhxrBQ8UeiWbGHNAc7opUZ0E/o7ILUFxqT7CHcSY jfd/yviezawmOpPmEOAF+1RGLtUhBVQKPg0H35y4f0mz7aVhNjEmdOyq9yVM2ttSiNoPAi edMBzzYXevezhDdAdquSQSpFBz6ZWuYZqxQfYt/ezVgPc8L9rPMCWKZrgAIXrw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1741106821; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vR6pZ30gVviHwhRnL/cOMtBZ0Ct99MYr3YiiiocJz6M=; b=UJsX2Xn5vqxMBIeVxA33kd0a1pQtx75zQG4oYsJOoQDB9JQIpcXM4Z8d47zDrLtsWfqs63 k1fMs0OFoYtb09jBYnxpBEWigCJQIMWVpNRCzRWLUVVp/y0SZniNWnSun5AT34iIdakpen pNn35aeMvihjQDHgXyWhH0vp/FoWuTqfHWvyAhnRa7AxL828jgXx8vVmXU0CYaoAuVnNVZ y3pBJeshZ7HqSLvDbcG9lZQfm3JI5EhAdgSM6DaUb7OTMtUZFSJZDXFnrNLk24JMUFt4+6 jjkJmrba9SG/7QbUHCzv+0U5CzhMLMFRsSVbHgsv/V0QCZ5U8EhmcMos8O9xBw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Z6hRT1nZ0z9hg for ; Tue, 04 Mar 2025 16:47:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 524Gl1e1001507 for ; Tue, 4 Mar 2025 16:47:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 524Gl1Hf001506 for virtualization@FreeBSD.org; Tue, 4 Mar 2025 16:47:01 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 279901] glibc-2.39-2 and above on the host segfault Date: Tue, 04 Mar 2025 16:46:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bhyve X-Bugzilla-Version: 14.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: mp@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: virtualization@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-virtualization@freebsd.org Sender: owner-freebsd-virtualization@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D279901 --- Comment #69 from Mark Peek --- Having just received an AMD 7840U I wanted to do a little more research into this bug and the current patch. Given the cache values I am seeing I believe the patch needs a small change. Looking at the cache output from ld.so --list-diagnostics without the patch, i.e., the current code: x86.cpu_features.data_cache_size=3D0x8000 x86.cpu_features.shared_cache_size=3D0x1000000000 x86.cpu_features.level1_icache_size=3D0x8000 x86.cpu_features.level1_icache_linesize=3D0x40 x86.cpu_features.level1_dcache_size=3D0x8000 x86.cpu_features.level1_dcache_assoc=3D0x8 x86.cpu_features.level1_dcache_linesize=3D0x40 x86.cpu_features.level2_cache_size=3D0x100000 x86.cpu_features.level2_cache_assoc=3D0x8 x86.cpu_features.level2_cache_linesize=3D0x40 x86.cpu_features.level3_cache_size=3D0x1000000000 x86.cpu_features.level3_cache_assoc=3D0x0 x86.cpu_features.level3_cache_linesize=3D0x40 x86.cpu_features.level4_cache_size=3D0x0 x86.cpu_features.cachesize_non_temporal_divisor=3D0x4 As Florian states in #36, the L3 cache size reporting 1TB is what triggers = the bug in glibc-2.40 (or a patched 2.39). Applying the patch from https://reviews.freebsd.org/D48187 gives these cache values: x86.cpu_features.data_cache_size=3D0x80 x86.cpu_features.shared_cache_size=3D0x2 x86.cpu_features.level1_icache_size=3D0x80 x86.cpu_features.level1_icache_linesize=3D0x40 x86.cpu_features.level1_dcache_size=3D0x80 x86.cpu_features.level1_dcache_assoc=3D0x1 x86.cpu_features.level1_dcache_linesize=3D0x40 x86.cpu_features.level2_cache_size=3D0x80 x86.cpu_features.level2_cache_assoc=3D0x1 x86.cpu_features.level2_cache_linesize=3D0x40 x86.cpu_features.level3_cache_size=3D0x2 x86.cpu_features.level3_cache_assoc=3D0x1 x86.cpu_features.level3_cache_linesize=3D0x1 x86.cpu_features.level4_cache_size=3D0x0 x86.cpu_features.cachesize_non_temporal_divisor=3D0x4 While the guest apps now work, the cache sizes are too small and not realis= tic. This is due to cpuid 0x8000001D not being fully implemented. Looking at the glibc code: =20=20=20=20 https://github.com/bminor/glibc/blob/glibc-2.40/sysdeps/x86/dl-cacheinfo.h#= L309 As Florian talks about in #39, the handle_amd() function first looks at cpu= id 0x8000001D for the cache information which is not providing all of the parameters needed to compute the correct cache sizes. If 0x8000001D is not available or the returned ecx=3D=3D0, it falls back to a legacy mechanism. = But for Zen architecture will also look at the 0x8000001D eax for the NumSharingCac= he. To get this fallback to work properly I reverted one of the changes in the proposed patch from Konstantin and only used: --- a/sys/amd64/vmm/x86.c +++ b/sys/amd64/vmm/x86.c @@ -150,8 +150,6 @@ x86_emulate_cpuid(struct vcpu *vcpu, uint64_t *rax, uint64_t *rbx, * pkg_id_shift and other OSes may rely on = it. */ width =3D MIN(0xF, log2(threads * cores)); - if (width < 0x4) - width =3D 0; logical_cpus =3D MIN(0xFF, threads * cores = - 1); regs[2] =3D (width << AMDID_COREID_SIZE_SHI= FT) | logical_cpus; } @@ -256,7 +254,7 @@ x86_emulate_cpuid(struct vcpu *vcpu, uint64_t *rax, uint64_t *rbx, func =3D 3; /* unified cache */ break; default: - logical_cpus =3D 0; + logical_cpus =3D sockets * threads * cores; level =3D 0; func =3D 0; break; The reverted change will keep 0x8000001D ecx=3D=3D0 to prevent 0x8000001D u= se in handle_amd() while still setting a better value for NumSharingCache for use= in the legacy code path. The reported cache sizes with this change shows: x86.cpu_features.data_cache_size=3D0x8000 x86.cpu_features.shared_cache_size=3D0x2000000 x86.cpu_features.level1_icache_size=3D0x8000 x86.cpu_features.level1_icache_linesize=3D0x40 x86.cpu_features.level1_dcache_size=3D0x8000 x86.cpu_features.level1_dcache_assoc=3D0x8 x86.cpu_features.level1_dcache_linesize=3D0x40 x86.cpu_features.level2_cache_size=3D0x100000 x86.cpu_features.level2_cache_assoc=3D0x8 x86.cpu_features.level2_cache_linesize=3D0x40 x86.cpu_features.level3_cache_size=3D0x2000000 x86.cpu_features.level3_cache_assoc=3D0x0 x86.cpu_features.level3_cache_linesize=3D0x40 x86.cpu_features.level4_cache_size=3D0x0 x86.cpu_features.cachesize_non_temporal_divisor=3D0x4 These values look more reasonable and fixes the guest issues on my system. Would like see if this matches what other people are seeing for cache sizes with this patch and if it resolves any outstanding issues. --=20 You are receiving this mail because: You are the assignee for the bug.=