From: "Fan, Jeff" <jeff.fan@intel.com>
To: Laszlo Ersek <lersek@redhat.com>,
"edk2-devel@ml01.01.org" <edk2-devel@ml01.01.org>
Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>,
"Tian, Feng" <feng.tian@intel.com>,
"Yao, Jiewen" <jiewen.yao@intel.com>
Subject: Re: [PATCH] UefiCpuPkg/CpuDxe: Add Local APIC memory mapped space in gDS
Date: Tue, 21 Feb 2017 01:33:11 +0000 [thread overview]
Message-ID: <542CF652F8836A4AB8DBFAAD40ED192A4C540B8D@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <c07bf826-997c-26ac-825a-de2388814dde@redhat.com>
Laszlo,
I added my feedback as below. Thanks!
-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com]
Sent: Monday, February 20, 2017 5:11 PM
To: Fan, Jeff; edk2-devel@ml01.01.org
Cc: Kinney, Michael D; Tian, Feng; Yao, Jiewen
Subject: Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Add Local APIC memory mapped space in gDS
Hi Jeff,
On 02/20/17 09:40, Jeff Fan wrote:
> Local APIC memory mapped space should be added into gDS and be allocated.
> Otherwise, UEFI firmware cannot get correct memory map for it. For
> example, SMM profile feature needs to get the completed MMIO map to protect them.
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=390
>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Cc: Feng Tian <feng.tian@intel.com>
> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan <jeff.fan@intel.com>
> ---
> UefiCpuPkg/CpuDxe/CpuDxe.c | 39
> +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c
> index 9fb6d76..71a08cd 100644
> --- a/UefiCpuPkg/CpuDxe/CpuDxe.c
> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
> @@ -887,6 +887,40 @@ IdleLoopEventCallback (
> CpuSleep ();
> }
>
> +/**
> + Add and allocate CPU local APIC memory mapped space.
> +
> + @param[in]ImageHandle Image handle this driver.
> +
> +**/
> +VOID
> +AddLocalApicMemorySpace (
> + IN EFI_HANDLE ImageHandle
> + )
> +{
> + EFI_STATUS Status;
> + EFI_PHYSICAL_ADDRESS BaseAddress;
> +
> + BaseAddress = (EFI_PHYSICAL_ADDRESS) GetLocalApicBaseAddress ();
> + Status = gDS->AddMemorySpace (
> + EfiGcdMemoryTypeMemoryMappedIo,
> + BaseAddress,
> + SIZE_4KB,
> + EFI_MEMORY_UC
> + );
> + ASSERT_EFI_ERROR (Status);
(1) This would break OVMF:
> Loading driver at 0x0007F510000 EntryPoint=0x0007F51027B CpuDxe.efi
> InstallProtocolInterface: [EfiLoadedImageDevicePathProtocol] 7EE08498
> InstallProtocolInterface: [EfiCpuArchProtocol] 7F522480
> Flushing GCD
> Flushing GCD
> Flushing GCD
> Flushing GCD
> Flushing GCD
> Flushing GCD
> Flushing GCD
> Flushing GCD
> Flushing GCD
> Flushing GCD
> Flushing GCD
> Flushing GCD
>
> ASSERT_EFI_ERROR (Status = Access Denied) ASSERT
> .../UefiCpuPkg/CpuDxe/CpuDxe.c(891): !EFI_ERROR (Status)
The reason for the assertion failure is that we add an uncacheable MMIO resource descriptor HOB for the LAPIC range earlier, in OvmfPkg/PlatformPei. When DXE starts up, it initializes the GCD memory space accordingly, hence the above addition failure.
There was a similar issue in PciHostBridgeDxe: originally it tried to add uncacheable MMIO space for the PCI bridges' apertures, unconditionally. The solution was to check the GCD memory space map, and:
- for any existing, overlapping entries, check if their attributes were compatible with UC,
- missing gaps were filled with new additions.
Please see commit 6474f1f156ee ("MdeModulePkg/PciHostBridge: Don't assume resources are fully NonExistent", 2016-02-25).
[Jeff] I agree. Platform Pei could use resource HOB to declare this range. I may sync the code from 6474f1f156ee to CpuDxe.
(2) After the memory space addition, the allocation should be attempted, I agree. But for that too, if it fails, that shouldn't be a fatal error.
[Jeff] Actually, I don't think there is other module(except for Cpu Driver) allocating such range. If other module does it, we need to think if it does make sense and how to fix it.
Thanks
Laszlo
> +
> + Status = gDS->AllocateMemorySpace (
> + EfiGcdAllocateAddress,
> + EfiGcdMemoryTypeMemoryMappedIo,
> + 0,
> + SIZE_4KB,
> + &BaseAddress,
> + ImageHandle,
> + NULL
> + );
> + ASSERT_EFI_ERROR (Status);
> +}
>
> /**
> Initialize the state information for the CPU Architectural Protocol.
> @@ -947,6 +981,11 @@ InitializeCpu (
> RefreshGcdMemoryAttributes ();
>
> //
> + // Add and allocate local APIC memory mapped space //
> + AddLocalApicMemorySpace (ImageHandle);
> +
> + //
> // Setup a callback for idle events
> //
> Status = gBS->CreateEventEx (
>
next prev parent reply other threads:[~2017-02-21 1:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-20 8:40 [PATCH] UefiCpuPkg/CpuDxe: Add Local APIC memory mapped space in gDS Jeff Fan
2017-02-20 9:11 ` Laszlo Ersek
2017-02-21 1:33 ` Fan, Jeff [this message]
2017-02-21 8:32 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=542CF652F8836A4AB8DBFAAD40ED192A4C540B8D@shsmsx102.ccr.corp.intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox