From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by mx.groups.io with SMTP id smtpd.web10.2814.1615445662464568060 for ; Wed, 10 Mar 2021 22:54:22 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@solid-run-com.20150623.gappssmtp.com header.s=20150623 header.b=Bs3MKedE; spf=pass (domain: solid-run.com, ip: 209.85.208.50, mailfrom: jon@solid-run.com) Received: by mail-ed1-f50.google.com with SMTP id bf3so1077749edb.6 for ; Wed, 10 Mar 2021 22:54:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=solid-run-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wyybb0pZlRHWQZb8GHwjXqnTFlW+jPkm5n9XeAorQTE=; b=Bs3MKedEQa90RlvMU31XIUQ3qE0UHGuKBMnVrM+DcAhRBtRw4sCw1lkx6MJxvS0qjA 21E/5IvfbudHalHVEffH8wDNyp8NuRZIiiq5/npJUTer6d7Go074EKzuLZK6IG41PuBx pTmo8exyTS66j8S5H0dbm0ElNCkv1PpwzKIlLNiwr6FkrhtObZ/lYm5oEv2UhZF7gRqw tuIN2r0EhWr7Q06O03rx3S7nJYw2x1OitOEDNA3CL1BUz8sLGGwtskG8v6e9O90r8hQf qyHCYdZaW5Nk+jTe2aK6PxhCkA/Mx0/UjRwDKcpA8FeGV/0A1hx2bQ2CUb3L0P6f/Rlv 9eKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wyybb0pZlRHWQZb8GHwjXqnTFlW+jPkm5n9XeAorQTE=; b=fF4AMvAt9w/90VlkRGB/rchW67cZwAwga8fe/+6LiQK0qm4ZEUh2rhYRkpH4ygnkyr wvKLp6RvIEfBeBHCuNbWuCZyfmCQFGPv7G2nu5u+WYDw0YuHyggaftsltRHYwovrVW33 m5jPQ/nqa4KZyZ9CHie6I1pySH3/ANCfcZJ2vsIOV67dEdDjXkNIGyA6mKCch9spDd2l zfPRFJxxbzJc0RPuDXp7wT7SzK9TxDD0xlHnJKD2UxwxA53HiPrLuRRk2DyHOhKYww69 iLoTosjMz7Jt68MK+WM8S3rcUxhimOvwUxWUoeWsZvjk9s5spQ9O0iWsuH14OuAQvk14 8RYw== X-Gm-Message-State: AOAM533iUp+Scnv1aViQ9rCGP64wxkaXawmjdyWI6J7M5I04v+LSo2U1 6jdJHgVKZyRAjSF2yboRVWesed2TynUmvLkMSItAww== X-Google-Smtp-Source: ABdhPJyZTtI4vgpqRtuIlQgfx6IaubdAgTC6BkSMjgy+BJVN8jpUbKePXrYEo8L60eZRgta8zgTEJh9cJJn0nPu1PHg= X-Received: by 2002:a05:6402:31a7:: with SMTP id dj7mr7028657edb.33.1615445660907; Wed, 10 Mar 2021 22:54:20 -0800 (PST) MIME-Version: 1.0 References: <5363bdf0-afac-73bf-d001-77949916f511@redhat.com> In-Reply-To: <5363bdf0-afac-73bf-d001-77949916f511@redhat.com> From: "Jon Nettleton" Date: Thu, 11 Mar 2021 07:53:42 +0100 Message-ID: Subject: Re: [edk2-devel] Conflicting virtual addresses causing Runtime Services issues To: Laszlo Ersek Cc: devel@edk2.groups.io Content-Type: text/plain; charset="UTF-8" On Wed, Mar 10, 2021 at 3:52 PM Laszlo Ersek wrote: > > On 03/10/21 09:04, Jon Nettleton wrote: > > I am debugging a failure that I am seeing while using the HoneyComb's > > spi-nor flash for runtime variable storage. I am hoping someone on > > the list can give me some insight as what may be the problem. > > > > The problem showed up when we switched the MMIO region for the fspi > > flash device to be marked as non executable. reading variables is > > fine, however writes began throwing an error. > > > > [ 556.709828] Unable to handle kernel execute from non-executable > > memory at virtual address 00000000206a3968 > > > > I have patched the kernel and removed the X86 requirement and enabled > > the sysfs runtime mappings kernel config so I can get an easy view of > > the mappings the kernel carries for runtime services. I then track > > that virtual address to the MMIO region of nor flash, which makes > > sense that region is marked as non executable. The question is why is > > code being executed from this address range > > > > attribute > > :::::::::::::: > > 0x8000000000000001 > > :::::::::::::: > > num_pages > > :::::::::::::: > > 0x40 > > :::::::::::::: > > phys_addr > > :::::::::::::: > > 0x20500000 > > :::::::::::::: > > type > > :::::::::::::: > > 0xb > > :::::::::::::: > > virt_addr > > :::::::::::::: > > 0x20680000 > > > > So then I patched the PL011 serial driver to be able to log to the > > console in runtime and I track down the access to Status = > > Fvb->GetPhysicalAddress(Fvb, &FvVolHdr); in UpdateVariableStore(). > > What I don't understand is why EfiConvertPointer is mapping that > > pointer into the Virtual address space occupied by the runtime mmio of > > the flash. The pointer is being properly remapped. Here are the > > pointer addresses in EFI and Kernel Runtime > > > > EFI: > > UpdateVariableStore:156 ECE33968 > > FvbGetPhysicalAddress(BaseAddress=0x20000000) > > > > KERNEL: > > UpdateVariableStore:156 206A3968 > > [ 556.709828] Unable to handle kernel execute from non-executable > > memory at virtual address 00000000206a3968 > > > > Any insight that anyone could provide would be much appreciated. > > Your platform appears misconfigured -- the flash MMIO range appears to > overlap runtime services code even before SetVirtualAddressMap. The > virtual address conflict is likely the result of the original physical > address conflict. There is no physical address conflict. Running in physical mode the pointer for GetPhysicalAddress is at 0xECE33968 and the MMIO physical region is 0x20000000 - 0x2FFFFFFF. Shown as the BaseAddress above. Obviously I don't use that full MMIO region because our flash is not 256MB. > > After the virtual address updates, the EfiMemoryMappedIO (0xb) type > range is mapped at virtual address range [0x20680000, 0x206C0000). The > GetPhysicalAddress function seems to be located at offset 0x23968 in > that range (with 0x1C698 bytes to go in the range). That's inexplicable. Yes, exactly why I am reaching out. > > What is the physical base address of the flash? What are the PCDs used > in "ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvb.c"? We don't use the ArmPlatformPkg The code is available here. https://github.com/SolidRun/edk2-platforms/tree/LX2160_UEFI_ACPI_EAR3-lx2160cex7/Silicon/NXP/Drivers/SpiNorFlashDxe Thanks > > Laszlo >