From nobody Wed Dec 18 11:24:45 2024 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 4YCrtn4QN3z5hDQT for ; Wed, 18 Dec 2024 11:24:49 +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 4YCrtn2sZPz41Fm for ; Wed, 18 Dec 2024 11:24:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1734521089; 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=CWoQunwTfzgP9dfWsVNVrx/y321CojQqnxsZAoA11bg=; b=hCFDAtvd/gHck5tq/QO90wpsGnFhNGhFbddzE5IaQzmKmrQXA5FW567duRo5kwUiJrr5lg l7C95reSYgDPPVlx6ESNfDnXZpByFe8ts3o8MigT/hu79qUx89VMfA2QnGrniuu5nuvd3P OQ5t2V0SD3wKNOe/XkDeeizf8atCU/rMRZRUZoGY+q6ISyakoZ6ppRNFvUL2kVzBZavN4u fHivoCeF3gp8HAZYwBPH+SX8R1glP4w/mnrGjbxjvwhaZG8t/94xl7hmbcihob5VD/n0PF LpfIldUX6IrpcGns1hG4d4V9zUcuIr2z9s/DkVuJJk3Yen/obMK7tfcTX5wc5g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1734521089; a=rsa-sha256; cv=none; b=NR16w4rXXeyxY+c0dqrfrnTz+v7V1thllzSwgpZsSYrdVDBWrHKACZs8Q5KhbCr5nJpW0S GVshfl+gs2SIHk89n2CgBvfcY/f87Tqv7qEbsgxAIa0aTcIZhVTuDFPeoX2kVq7SWzBstB jlr7VFyQt3pQ33ImkQ5ydwt3XWqeqNbDlUjUnUaZxpFnBhKlspC+Gq/9zHDmCbAGJJYh+u qtdvZRXT5jmi6gTXM7T1L99VkA+mqaDEItuqn4hgcT4HNuQxnmRrQu1y7OB8f+Zd08WCcr tsZ+hk0t0ZLehlyFsyxaZFxPIk2ijan7BIm12ow+aEdcNucrxk4KBfpoml4y1A== 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 4YCrtn2FX6z15yx for ; Wed, 18 Dec 2024 11:24:49 +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 4BIBOnJx082423 for ; Wed, 18 Dec 2024 11:24:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4BIBOndI082421 for virtualization@FreeBSD.org; Wed, 18 Dec 2024 11:24:49 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: Wed, 18 Dec 2024 11:24:45 +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: fweimer@redhat.com 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-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 #39 from Florian Weimer --- (In reply to Konstantin Belousov from comment #37) > Do you see which CPUID leaf causes the trouble? Let me try based on attachment 255708. The maximum leaf is 0x80000023 accor= ding to this: x86.processor[0x0].cpuid.eax[0x80000000].eax=3D0x80000023 Ordinarly, handle_amd in sysdeps/x86/dl-cacheinfo.h would use the modern way for obtaining cache details, using leaf 0x8000001D: x86.processor[0x0].cpuid.subleaf_eax[0x8000001d].ecx[0x0].eax=3D0x121 x86.processor[0x0].cpuid.subleaf_eax[0x8000001d].ecx[0x0].ebx=3D0x3f x86.processor[0x0].cpuid.subleaf_eax[0x8000001d].ecx[0x0].ecx=3D0x0 x86.processor[0x0].cpuid.subleaf_eax[0x8000001d].ecx[0x0].edx=3D0x0 x86.processor[0x0].cpuid.subleaf_eax[0x8000001d].ecx[0x1].eax=3D0x143 x86.processor[0x0].cpuid.subleaf_eax[0x8000001d].ecx[0x1].ebx=3D0x3f x86.processor[0x0].cpuid.subleaf_eax[0x8000001d].ecx[0x1].ecx=3D0x0 x86.processor[0x0].cpuid.subleaf_eax[0x8000001d].ecx[0x1].edx=3D0x0 x86.processor[0x0].cpuid.subleaf_eax[0x8000001d].ecx[0x2].eax=3D0x163 x86.processor[0x0].cpuid.subleaf_eax[0x8000001d].ecx[0x2].ebx=3D0x3f x86.processor[0x0].cpuid.subleaf_eax[0x8000001d].ecx[0x2].ecx=3D0x0 x86.processor[0x0].cpuid.subleaf_eax[0x8000001d].ecx[0x2].edx=3D0x0 x86.processor[0x0].cpuid.subleaf_eax[0x8000001d].ecx[0x3].eax=3D0x3ffc100 x86.processor[0x0].cpuid.subleaf_eax[0x8000001d].ecx[0x3].ebx=3D0x0 x86.processor[0x0].cpuid.subleaf_eax[0x8000001d].ecx[0x3].ecx=3D0x0 x86.processor[0x0].cpuid.subleaf_eax[0x8000001d].ecx[0x3].edx=3D0x0 x86.processor[0x0].cpuid.subleaf_eax[0x8000001d].ecx[0x3].until_ecx=3D0x1ff L3 cache data is subleaf 3. We have a safety check that requires ECX !=3D 0= , in case hypervisors do not fill in this information, which is happening here. = We fall back to the legacy way of obtaining cache size. That uses leaf 0x8000= 0006 for L3 cache information: x86.processor[0x0].cpuid.eax[0x80000006].eax=3D0x48002200 x86.processor[0x0].cpuid.eax[0x80000006].ebx=3D0x68004200 x86.processor[0x0].cpuid.eax[0x80000006].ecx=3D0x2006140 x86.processor[0x0].cpuid.eax[0x80000006].edx=3D0x8009140 The base L3 cache size is 2 * (EDX & 0x3ffc0000), so 256 MIB. This is not unreasonable for an EPYC system, and it's probably right. However, that number could be a per-socket number, and the way we use this number for tuning, we need a per-thread amount. We adjust this per leaf 0x80000008. The thread count is in (ECX & 0xff) + 1: x86.processor[0x0].cpuid.eax[0x80000008].eax=3D0x3030 x86.processor[0x0].cpuid.eax[0x80000008].ebx=3D0x7 x86.processor[0x0].cpuid.eax[0x80000008].ecx=3D0x0 x86.processor[0x0].cpuid.eax[0x80000008].edx=3D0x10007 So we get 1, and there is no per-thread scale-down. (I think the hypervisor should expose a more realistic count here?) If the CPU family is at least 0x17, we assume that the number is measured p= er core complex. And that comes again from leaf 0x8000001d, subleaf 3, but this time register EAX. It's computed as (EAX >> 14 & 0xfff) + 1. This evaluates= to 4096 here, and I think this is the bug. This CCX count is just way too high. Based on the available information, the glibc code assumes that there are 4= 096 instances of 256 MiB caches, which translates to 1 TiB of L3 cache (per thr= ead, but the thread count is 1). --=20 You are receiving this mail because: You are the assignee for the bug.=