summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/XenPlatformPei
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/OvmfXen: Set PcdFSBClockAnthony PERARD2021-04-132-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update gEfiMdePkgTokenSpaceGuid.PcdFSBClock so it can have the correct value when SecPeiDxeTimerLibCpu start to use it for the APIC timer. Currently, nothing appear to use the value in PcdFSBClock before XenPlatformPei had a chance to set it even though TimerLib is included in modules run before XenPlatformPei. XenPlatformPei doesn't use any of the functions that would use that value. No other modules in the PEI phase seems to use the TimerLib before PcdFSBClock is set. There are currently two other modules in the PEI phase that needs the TimerLib: - S3Resume2Pei, but only because LocalApicLib needs it, but nothing is using the value from PcdFSBClock. - CpuMpPei, but I believe it only runs after XenPlatformPei Before the PEI phase, there's the SEC phase, and SecMain needs TimerLib because of LocalApicLib. And it initialise the APIC timers for the debug agent. But I don't think any of the DebugLib that OvmfXen could use are actually using the *Delay functions in TimerLib, and so would not use the value from PcdFSBClock which would be uninitialised. A simple runtime test showed that TimerLib doesn't use PcdFSBClock value before it is set. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210412133003.146438-8-anthony.perard@citrix.com> [lersek@redhat.com: cast Freq to UINT32 for PcdSet32S(), not for ASSERT()]
* OvmfPkg/XenPlatformPei: Calibrate APIC timer frequencyAnthony PERARD2021-04-134-0/+185
| | | | | | | | | | | | | | | | | | | | | | | | | Calculate the frequency of the APIC timer that Xen provides. Even though the frequency is currently hard-coded, it isn't part of the public ABI that Xen provides and thus may change at any time. OVMF needs to determine the frequency by an other mean. Fortunately, Xen provides a way to determines the frequency of the TSC, so we can use TSC to calibrate the frequency of the APIC timer. That information is found in the shared_info page which we map and unmap once done (XenBusDxe is going to map the page somewhere else). The shared_info page is mapped at the highest physical address allowed as it doesn't need to be in the RAM, thus there's a call to update the page table. The calculated frequency is only logged in this patch, it will be used in a following patch. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210412133003.146438-7-anthony.perard@citrix.com>
* OvmfPkg/XenPlatformPei: Map extra physical addressAnthony PERARD2021-04-133-0/+77
| | | | | | | | | | | | | | | | | | | | | | Some information available in a Xen guest can be mapped anywhere in the physical address space and they don't need to be backed by RAM. For example, the shared info page. While it's easier to put those pages anywhere, it is better to avoid mapping it where the RAM is. It might split a nice 1G guest page table into 4k pages and thus reducing performance of the guest when it accesses its memory. Also mapping a page like the shared info page and then unmapping it or mapping it somewhere else would leave a hole in the RAM that the guest would propably not be able to use anymore. So the patch introduces a new function which can be used to 1:1 mapping of guest physical memory above 4G during the PEI phase so we can map the Xen shared pages outside of memory that can be used by guest, and as high as possible. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210412133003.146438-6-anthony.perard@citrix.com>
* OvmfPkg/XenPlatformPei: Use CPUID to get physical address width on XenIgor Druzhinin2021-01-191-154/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We faced a problem with passing through a PCI device with 64GB BAR to UEFI guest. The BAR is expectedly programmed into 64-bit PCI aperture at 64G address which pushes physical address space to 37 bits. That is above 36-bit width that OVMF exposes currently to a guest without tweaking PcdPciMmio64Size knob. The reverse calculation using this knob was inhereted from QEMU-KVM platform code where it serves the purpose of finding max accessible physical address without necessary trusting emulated CPUID physbits value (that could be different from host physbits). On Xen we expect to use CPUID policy to level the data correctly to prevent situations with guest physbits > host physbits e.g. across migrations. The next aspect raising concern - resource consumption for DXE IPL page tables and time required to map the whole address space in case of using CPUID bits directly. That could be mitigated by enabling support for 1G pages in DXE IPL configuration. 1G pages are available on most CPUs produced in the last 10 years and those without don't have many phys bits. Remove all the redundant code now (including PcdPciMmio64.. handling that's not used on Xen anyway) and grab physbits directly from CPUID that should be what baremetal UEFI systems do. Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com> Message-Id: <1610509335-23314-1-git-send-email-igor.druzhinin@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Julien Grall <julien@xen.org> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> [lersek@redhat.com: fix up authorship from groups.io-mangled From line] [lersek@redhat.com: wrap commit message at 74 characters]
* OvmfPkg: Obtain SEV encryption mask with the new MemEncryptSevLib APITom Lendacky2021-01-071-10/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 The early assembler code performs validation for some of the SEV-related information, specifically the encryption bit position. The new MemEncryptSevGetEncryptionMask() interface provides access to this validated value. To ensure that we always use a validated encryption mask for an SEV-ES guest, update all locations that use CPUID to calculate the encryption mask to use the new interface. Also, clean up some call areas where extra masking was being performed and where a function call was being used instead of the local variable that was just set using the function. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <9de678c0d66443c6cc33e004a4cac0a0223c2ebc.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVHAnthony PERARD2019-08-211-0/+6
| | | | | | | | | | When the device ID of the host bridge is unknown, check if we are running as a PVH guest as there is no PCI bus in that case. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-26-anthony.perard@citrix.com>
* OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot LinuxAnthony PERARD2019-08-211-0/+16
| | | | | | | | | | | | | | | | | Linux panic if the VGA region isn't reserved. When Linux is booted on EFI system, it expects the memory at 0xa0000 to _not_ be conventional memory. Otherwise a variable isn't initialised properly and Linux panic when a virtual console/terminal is asked to be created. See for more detail: https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg02139.html Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-25-anthony.perard@citrix.com>
* OvmfPkg/XenPlatformPei: Rework memory detectionAnthony PERARD2019-08-214-22/+148
| | | | | | | | | | | | | | | | | | | | | When running as a Xen PVH guest, there is no CMOS to read the memory size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can work without CMOS by reading the e820 table. Rework XenPublishRamRegions to also care for the reserved and ACPI entry in the e820 table. The region that was added by InitializeXen() isn't needed as that same entry is in the e820 table provided by hvmloader. MTRR settings aren't modified anymore, on HVM it's already done by hvmloader, on PVH it is supposed to have sane default. MTRR will need to be done properly but keeping what's already been done by programs that have run before OVMF will do for now. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-24-anthony.perard@citrix.com>
* OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercallAnthony PERARD2019-08-211-1/+45
| | | | | | | | | | | | When the Xen PVH entry point has been used, hvmloader hasn't run and hasn't prepared an E820 table. The only way left to get an E820 table is to ask Xen via an hypercall. We keep the result cached to avoid making a second hypercall which would give the same result. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-23-anthony.perard@citrix.com>
* OvmfPkg/XenPlatformPei: Introduce XenPvhDetectedAnthony PERARD2019-08-212-0/+18
| | | | | | | | | | XenPvhDetected() can be used to figure out if OVMF has started via the Xen PVH entry point. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-21-anthony.perard@citrix.com>
* OvmfPkg/XenPlatformPei: Setup HyperPages earlierAnthony PERARD2019-08-213-11/+19
| | | | | | | | | | | | | | | We are going to need to make an hypercall in order to retreive the E820 table from the hypervisor before been able to setup the memory. Calling XenConnect earlier will allow to setup the XenHypercallLib earlier to allow to make hypercalls. While here, add some comments in XenConnect(). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-20-anthony.perard@citrix.com>
* OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetectedAnthony PERARD2019-08-212-0/+12
| | | | | | | | | | This new XenHvmloaderDetected() return true if the hvmloader firmware has runned before OVMF. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-19-anthony.perard@citrix.com>
* OvmfPkg/XenPlatformPei: Reinit XenHypercallLibAnthony PERARD2019-08-212-0/+10
| | | | | | | | | | | The XenPlatformPei needs to make hypercalls, but the XenHypercallLib was initialised before the HyperPage was ready. Now that XenPlatformPei has initialised the HyperPage, reinitialise the XenHypercallLib. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-18-anthony.perard@citrix.com>
* OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day structAnthony PERARD2019-08-212-0/+28
| | | | | | | | | | | | Check if there's a start of the day struct provided to PVH guest, save the ACPI RSDP address for later. This patch import import arch-x86/hvm/start_info.h from xen.git. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-13-anthony.perard@citrix.com>
* OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820Anthony PERARD2019-08-211-9/+9
| | | | | | | | | | Use the already checked pointer mXenHvmloaderInfo to retrieve the E820 table produced by hvmloader. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-12-anthony.perard@citrix.com>
* OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloaderAnthony PERARD2019-08-211-2/+23
| | | | | | | | | | | | | | EFI_XEN_OVMF_INFO is only useful to retrieve the E820 table. The mXenHvmloaderInfo isn't used yet, but will be use in a further patch to retrieve the E820 table. Also remove the unused pointer from the XenInfo HOB as that information is only useful in the XenPlatformPei. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-11-anthony.perard@citrix.com>
* OvmfPkg: Introduce XenPlatformPeiAnthony PERARD2019-08-2111-0/+1691
Introduce XenPlatformPei, a copy of OvmfPkg/PlatformPei without some of QEMU specific initialization, Xen does not support QemuFwCfg. This new module will be adjusted to accommodate Xen PVH. fw_cfg dependents that have been removed, which are dynamically skipped when running PlatformPei on Xen: - GetFirstNonAddress(): controlling the 64-bit PCI MMIO aperture via the (experimental) "opt/ovmf/X-PciMmio64Mb" file - GetFirstNonAddress(): honoring the hotplug DIMM area ("etc/reserved-memory-end") in the placement of the 64-bit PCI MMIO aperture - NoexecDxeInitialization() is removed, so PcdPropertiesTableEnable and PcdSetNxForStack are left constant FALSE (not set dynamically from fw_cfg "opt/ovmf/PcdXxxx") - MaxCpuCountInitialization(), PublishPeiMemory(): the max CPU count is not taken from the QemuFwCfgItemSmpCpuCount fw_cfg key; PcdCpuMaxLogicalProcessorNumber is used intact and PcdCpuApInitTimeOutInMicroSeconds is never changed or used. - InitializeXenPlatform(), S3Verification(): S3 is assumed disabled (not consulting "etc/system-states" via QemuFwCfgS3Enabled()). - InstallFeatureControlCallback(): the feature control MSR is not set from "etc/msr_feature_control" (also removed FeatureControl.c as there is nothing been executed) Also removed: - SMRAM/TSEG-related low mem size adjusting (PcdSmmSmramRequire is assumed FALSE) in PublishPeiMemory(), - QemuInitializeRam() entirely, Xen related changes: - Have removed the module variable mXen, as it should be always true. - Have the platform PEI initialization fails if Xen has not been detected. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-5-anthony.perard@citrix.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-20 22:13:59 +0000