From nobody Tue Feb 10 00:59:35 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=linaro.org ARC-Seal: i=1; a=rsa-sha256; t=1590574040; cv=none; d=zohomail.com; s=zohoarc; b=hlb001H7oux7X9L3xJubLk6q1K3GY252u+d7ybNujNUagGszYFcBlbMaCfOMI3CZysMdAe9QnraHplKRsS9OTBJg36P4GXTKOLgg1ppWrNOpaHZ+Nw9bvFHEahrf0GFAI9jbBdmK/07X32TYQfsvYlqjorognKBjJorWq5Wdvgs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1590574040; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=b1rnVPfR5Tx3kSg0YJymoHV+oJytl6k3F5aYs9rOE0Y=; b=ZpDVDxmYZlEkIwwZgTldOXtmmrce8rg8eaLdoNOSMr6lvyaSFfY8E9uO9QKExkz1IWtpGf80z2IcUrSXUGuZ0vqALwXs2qDcgiWvQE8m28zHvUNWUSjnRQw3Ysr0aVX0jD6yD4HzZCXIEq0NHuxdrbjvbNgY4DWdDgg198C58As= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1590574040410579.4105397493986; Wed, 27 May 2020 03:07:20 -0700 (PDT) Received: from localhost ([::1]:53326 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdsxz-0005XY-7U for importer@patchew.org; Wed, 27 May 2020 06:07:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50276) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdswd-0003UI-V3 for qemu-devel@nongnu.org; Wed, 27 May 2020 06:05:55 -0400 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]:40713) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jdswc-0005D2-F8 for qemu-devel@nongnu.org; Wed, 27 May 2020 06:05:55 -0400 Received: by mail-wr1-x443.google.com with SMTP id j16so10962462wrb.7 for ; Wed, 27 May 2020 03:05:54 -0700 (PDT) Received: from zen.linaroharston ([51.148.130.216]) by smtp.gmail.com with ESMTPSA id t6sm2202626wma.4.2020.05.27.03.05.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 May 2020 03:05:50 -0700 (PDT) Received: from zen.lan (localhost [127.0.0.1]) by zen.linaroharston (Postfix) with ESMTP id 128271FF8C; Wed, 27 May 2020 11:05:47 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=b1rnVPfR5Tx3kSg0YJymoHV+oJytl6k3F5aYs9rOE0Y=; b=HSvZhak5TuyQi5IWGcjjOMlGbsZjF0Y+Pnnp7jg47KH8u9bziJp1RV+tyAD8bqemmj sc/d231xp3cX+xmGHphArsopMn6lH4g2eue939MRJSO1nEtp6Jj3Tk3yPfrwMK56wjfo SFiRSetkMr+HF+8kY22xMxhxb0X6xfXRQPxEQ2ylQ7GYpvdWMhKA0qcdjWSA/bVumNaK NEdKLeLeXzvfLE3oBy7g5IRI3lYpBGvjdfhDcdfQzVt0Od5/5KikGl0x2tUv/SrHCz0A 5NkszQYUfLpf36LG+LhnfKdleLh4PIGeovJAB/N5J3ouDj3YeUsiA6H2/s5xdju4BbPR Ux1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=b1rnVPfR5Tx3kSg0YJymoHV+oJytl6k3F5aYs9rOE0Y=; b=luCWEfqqms3TYeP7ofYO8ivXWwXIh7ajuvf8gOsQB7LYMzhMWslKF9LlcFLWmXZSRn imf+39Tq2L8bGNcXRFTR/iiEY1qLhVzIxxet9AtJ8X6ILP5evIR50AZ1yy+a5oDrwUs9 6Kq1FOp4LqV6IfjmfcOuFbpSLA6L6Hye/hAsmjLoEf+a5Q9MtCJNck38aRsq8KuQrAGc wj3aGBI2DtS17sjTg7AoslyW4r45om6yl0DH9FZE9rQpFJ6yWNnqEo2RhZpnrTTG4e1q u+EH7/eOheboVEaqO+f6Tcy/BY62A2lpPxvmAC9zBUkHUbboQHMa22VkFDE8bmzcqY0I q7/g== X-Gm-Message-State: AOAM530r04wcHUbiRyEryaRxsxNNJTvFtB8xHIGuO9a2efu+Ik8FyTXt 22uEf3iCj9tGW/6blS9fPCgm7w== X-Google-Smtp-Source: ABdhPJwQQYQvJ8dfw9OoTs7N7MoL/SPkhPy4dg/zXOcDNb6JejgS9x0+uuk0P+hSUaxQSDnKs9pCEA== X-Received: by 2002:adf:814a:: with SMTP id 68mr24367324wrm.177.1590573952701; Wed, 27 May 2020 03:05:52 -0700 (PDT) From: =?UTF-8?q?Alex=20Benn=C3=A9e?= To: qemu-devel@nongnu.org Subject: [PATCH v1 2/3] linux-user: deal with address wrap for ARM_COMMPAGE on 32 bit Date: Wed, 27 May 2020 11:05:45 +0100 Message-Id: <20200527100546.29297-3-alex.bennee@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200527100546.29297-1-alex.bennee@linaro.org> References: <20200527100546.29297-1-alex.bennee@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=2a00:1450:4864:20::443; envelope-from=alex.bennee@linaro.org; helo=mail-wr1-x443.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Bug 1880225 <1880225@bugs.launchpad.net>, Riku Voipio , Richard Henderson , Laurent Vivier , qemu-arm@nongnu.org, =?UTF-8?q?Alex=20Benn=C3=A9e?= Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) We rely on the pointer to wrap when accessing the high address of the COMMPAGE so it lands somewhere reasonable. However on 32 bit hosts we cannot afford just to map the entire 4gb address range. The old mmap trial and error code handled this by just checking we could map both the guest_base and the computed COMMPAGE address. We can't just manipulate loadaddr to get what we want so we introduce an offset which pgb_find_hole can apply when looking for a gap for guest_base that ensures there is space left to map the COMMPAGE afterwards. This is arguably a little inefficient for the one 32 bit value (kuser_helper_version) we need to keep there given all the actual code entries are picked up during the translation phase. Fixes: ee94743034b Bug: https://bugs.launchpad.net/qemu/+bug/1880225 Cc: Bug 1880225 <1880225@bugs.launchpad.net> Signed-off-by: Alex Benn=C3=A9e Cc: Richard Henderson Cc: Peter Maydell Tested-by: Aleksandar Markovic --- linux-user/elfload.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/linux-user/elfload.c b/linux-user/elfload.c index d6027867a1a..31defce95b5 100644 --- a/linux-user/elfload.c +++ b/linux-user/elfload.c @@ -2145,7 +2145,7 @@ static uintptr_t pgd_find_hole_fallback(uintptr_t gue= st_size, uintptr_t brk, lon =20 /* Return value for guest_base, or -1 if no hole found. */ static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_siz= e, - long align) + long align, uintptr_t offset) { GSList *maps, *iter; uintptr_t this_start, this_end, next_start, brk; @@ -2171,7 +2171,7 @@ static uintptr_t pgb_find_hole(uintptr_t guest_loaddr= , uintptr_t guest_size, =20 this_end =3D ((MapInfo *)iter->data)->start; next_start =3D ((MapInfo *)iter->data)->end; - align_start =3D ROUND_UP(this_start, align); + align_start =3D ROUND_UP(this_start + offset, align); =20 /* Skip holes that are too small. */ if (align_start >=3D this_end) { @@ -2221,6 +2221,7 @@ static void pgb_static(const char *image_name, abi_ul= ong orig_loaddr, { uintptr_t loaddr =3D orig_loaddr; uintptr_t hiaddr =3D orig_hiaddr; + uintptr_t offset =3D 0; uintptr_t addr; =20 if (hiaddr !=3D orig_hiaddr) { @@ -2234,18 +2235,19 @@ static void pgb_static(const char *image_name, abi_= ulong orig_loaddr, if (ARM_COMMPAGE) { /* * Extend the allocation to include the commpage. - * For a 64-bit host, this is just 4GiB; for a 32-bit host, - * the address arithmetic will wrap around, but the difference - * will produce the correct allocation size. + * For a 64-bit host, this is just 4GiB; for a 32-bit host we + * need to ensure there is space bellow the guest_base so we + * can map the commpage in the place needed when the address + * arithmetic wraps around. */ if (sizeof(uintptr_t) =3D=3D 8 || loaddr >=3D 0x80000000u) { hiaddr =3D (uintptr_t)4 << 30; } else { - loaddr =3D ARM_COMMPAGE & -align; + offset =3D (128 * KiB); } } =20 - addr =3D pgb_find_hole(loaddr, hiaddr - loaddr, align); + addr =3D pgb_find_hole(loaddr, hiaddr - loaddr, align, offset); if (addr =3D=3D -1) { /* * If ARM_COMMPAGE, there *might* be a non-consecutive allocation @@ -2280,7 +2282,7 @@ static void pgb_dynamic(const char *image_name, long = align) * just above that, and maximises the positive guest addresses. */ commpage =3D ARM_COMMPAGE & -align; - addr =3D pgb_find_hole(commpage, -commpage, align); + addr =3D pgb_find_hole(commpage, -commpage, align, 0); assert(addr !=3D -1); guest_base =3D addr; } --=20 2.20.1