From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail05.groups.io (mail05.groups.io [45.79.224.7]) by spool.mail.gandi.net (Postfix) with ESMTPS id 2A6E4740032 for ; Sat, 29 Jun 2024 15:26:56 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=vcTLjy/RFG8A8VFWZ6iARSOM5o0dvGNl0GbmpZfleOY=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Resent-From:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20240206; t=1719674815; v=1; b=cu7pckXQHQQI79PT1pHlQWmZlJ52HVlSgw6Xu5b6h3Ay5hp+0qGoRIjeLtX4wSVmbkQNuERs AkziTCYoxWOWEi+E7IYxEU4jkiVWasKJjDO/KSJJA7hNJPCKq/Y4hJFe3EbAFiPVmiyv+I1DhVQ k0dT81RADcVNPLvoW+sjfFXX21o5BnVGP7xxWZt3ViA1WtmmiH+9y2PKNkQAN9veTvzSSdfN0v8 LTYWvqbmLWkjQOxKFWz2Eg4QUyP0phXeMdYDQW25bzmd8j4/fC/IkWoQoIy3n6CqlCZUWiIqXzk SfQSWmsCxFd8MmrexZc0KWBEVpcFCCh3d1UuPOeyUm3Tw== X-Received: by 127.0.0.2 with SMTP id 491gYY7687511xsRjYDHGM5V; Sat, 29 Jun 2024 08:26:54 -0700 X-Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by mx.groups.io with SMTP id smtpd.web11.7994.1719674813696361265 for ; Sat, 29 Jun 2024 08:26:54 -0700 X-Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id B63ECCE102B for ; Sat, 29 Jun 2024 15:26:50 +0000 (UTC) X-Received: by smtp.kernel.org (Postfix) with ESMTPSA id F3088C2BBFC for ; Sat, 29 Jun 2024 15:26:49 +0000 (UTC) X-Received: by mail-lj1-f174.google.com with SMTP id 38308e7fff4ca-2ec5fad1984so21706801fa.0 for ; Sat, 29 Jun 2024 08:26:49 -0700 (PDT) X-Gm-Message-State: 7hmxpP6DmUVII7XG5dxt3tN9x7686176AA= X-Google-Smtp-Source: AGHT+IE4TJlbFuAz4KetOeLPti2M9Ip7eKIvJ568wbAZpOofVuk55LhK6lW9LXOweT3WZtD8PG4SnEKQGRqLesu/OiM= X-Received: by 2002:a05:651c:2051:b0:2ec:3d74:88c8 with SMTP id 38308e7fff4ca-2ee5e393f2emr9204401fa.18.1719674808393; Sat, 29 Jun 2024 08:26:48 -0700 (PDT) MIME-Version: 1.0 References: <428c3293-3899-4794-a51b-7670331e58a2@bsdio.com> In-Reply-To: <428c3293-3899-4794-a51b-7670331e58a2@bsdio.com> From: "Ard Biesheuvel" Date: Sat, 29 Jun 2024 17:26:37 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] Alignment fault in __memcpy when SbsaQemu is built uncompressed To: Rebecca Cran , Leif Lindholm Cc: "devel@edk2.groups.io" , Marcin Juszkiewicz Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Resent-Date: Sat, 29 Jun 2024 08:26:54 -0700 Resent-From: ardb@kernel.org Reply-To: devel@edk2.groups.io,ardb@kernel.org List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b=cu7pckXQ; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.224.7 as permitted sender) smtp.mailfrom=bounce@groups.io On Sat, 22 Jun 2024 at 20:04, Rebecca Cran wrote: > > I decided to do some testing around the cost of copying vs decompressing > and moved all the drivers in SbsaQemu into the uncompressed section (as > described in > https://github.com/tianocore/tianocore.github.io/wiki/ArmPkg-Compression), > but firmware built with CLANGDWARF causes an alignment fault when > writing the last 64 bytes in __memcpy via FvReadFile -> AllocateCopyPool > -> InternalAllocateCopyPool -> InternalMemCopyMem -> __memcpy > (AArch64/CopyMem.S in BaseMemoryLibOptDxe). > > > InternalAllocateCopyPool calls CopyMem with Memory=0x1000694d018, > Buffer=0x10a71300, AllocationSize=274476. > > The instruction that causes the fault is: > > ldp x14, x15, [x4, #-64] > > Where x4=0x10ab432c > It looks like the FvReadFile() call is doing a memory copy from the firmware volume (FV), which seems to be mapped with device attributes rather than normal memory. With a compressed image, the FV will be decompressed to normal RAM, so this can never happen at this stage in the boot (BDS phase) Looking at Platform/Qemu/SbsaQemu/SbsaQemu.fdf and Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c, the entire flash device (FD) which should cover the uncompressed FV is mapped with cacheable attributes, but the address in question ^^^ is outside of the predefined window of BaseAddress = 0x10000000|gArmTokenSpaceGuid.PcdFdBaseAddress Size = 0x003C0000|gArmTokenSpaceGuid.PcdFdSize Did you update PcdFdSize to account for the larger footprint of the FV? -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#119728): https://edk2.groups.io/g/devel/message/119728 Mute This Topic: https://groups.io/mt/106820121/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-