Commit Graph

27 Commits

Author SHA1 Message Date
Li Fei1
b4a23e6c13 hv: ept: build 4KB page mapping in EPT for code pages of rtvm
RTVM is enforced to use 4KB pages to mitigate CVE-2018-12207 and performance jitter,
which may be introduced by splitting large page into 4KB pages on demand. It works
fine in previous hardware platform where the size of address space for the RTVM is
relatively small. However, this is a problem when the platforms support 64 bits
high MMIO space, which could be super large and therefore consumes large # of
EPT page table pages.

This patch optimize it by using large page for purely data pages, such as MMIO spaces,
even for the RTVM.

Signed-off-by: Li Fei1 <fei1.li@intel.com>
Tracked-On: #5788
2021-03-11 12:36:17 +08:00
Li Fei1
38be61e374 hv: page: add free_page
Add free_page to free page when unmap pagetable.

Signed-off-by: Li Fei1 <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Tracked-On: #5788
2021-03-11 12:36:17 +08:00
Li Fei1
04a104e856 hv: page: use dynamic page allocation for pagetable mapping
For FuSa's case, we remove all dynamic memory allocation use in ACRN HV. Instead,
we use static memory allocation or embedded data structure. For pagetable page,
we prefer to use an index (hva for MMU, gpa for EPT) to get a page from a special
page pool. The special page pool should be big enougn for each possible index.
This is not a big problem when we don't support 64 bits MMIO. Without 64 bits MMIO
support, we could use the index to search addrss not larger than DRAM_SIZE + 4G.

However, if ACRN plan to support 64 bits MMIO in SOS, we could not use the static
memory alocation any more. This is because there's a very huge hole between the
top DRAM address and the bottom 64 bits MMIO address. We could not reserve such
many pages for pagetable mapping as the CPU physical address bits may very large.

This patch will use dynamic page allocation for pagetable mapping. We also need
reserve a big enough page pool at first. For HV MMU, we don't use 4K granularity
page table mapping, we need reserve PML4, PDPT and PD pages according the maximum
physical address space (PPT va and pa are identical mapping); For each VM EPT,
we reserve PML4, PDPT and PD pages according to the maximum physical address space
too, (the EPT address sapce can't beyond the physical address space), and we reserve
PT pages by real use cases of DRAM, low MMIO and high MMIO.

Signed-off-by: Li Fei1 <fei1.li@intel.com>
Tracked-On: #5788
2021-03-11 12:36:17 +08:00
Li Fei1
312702f2ec hv: memory: remove get_sworld_memory_base API
memory_ops structure will be changed to store page table related fields.
However, secure world memory base address is not one of them, it's VM
related. So save sworld_memory_base_hva in vm_arch structure directly.

Signed-off-by: Li Fei1 <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Tracked-On: #5788
2021-03-11 12:36:17 +08:00
Li Fei1
f3067f5385 hv: mmu: rename hv_access_memory_region_update to ppt_clear_user_bit
Rename hv_access_memory_region_update to ppt_clear_user_bit to
verb + object style.

Tracked-On: #5330
Signed-off-by: Li Fei1 <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-11-02 10:29:43 +08:00
Li Fei1
65e4a16e6a hv: mmu: release 1GB cpu side support constrain
There're some platforms still doesn't support 1GB large page on CPU side.
Such as lakefield, TNT and EHL platforms on which have some silicon bug and
this case CPU don't support 1GB large page.

This patch tries to release this constrain to support more hardware platform.

Note this patch doesn't release the constrain on IOMMU side.

Tracked-On: #4550
Signed-off-by: Li Fei1 <fei1.li@intel.com>
2020-06-15 15:16:34 +08:00
Sainath Grandhi
47f883db30 hv: Hypervisor access to PCI devices with 64-bit MMIO BARs
PCI devices with 64-bit MMIO BARs and requiring large MMIO space
can be assigned with physical address range at the very high end of
platform supported physical address space.

This patch uses the board info for 64-bit MMIO window as programmed
by BIOS and constructs 1G page tables for the same.

As ACRN uses identity mapping from Linear to Physical address space
physical addresses upto 48 bit or 256TB can be supported.

Tracked-On: #4586
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-04-13 16:52:18 +08:00
Sainath Grandhi
5958d6f65f hv: Fix issues with the patch to reserve EPT 4K pages after boot
This patch fixes couple of minor issues with patch 8ffe6fc6

Tracked-On: #4563
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
2020-04-03 11:06:14 +08:00
Sainath Grandhi
8ffe6fc67a hv: Reserve space for VMs' EPT 4k pages after boot
As ACRN prepares to support servers with large amounts of memory
current logic to allocate space for 4K pages of EPT at compile time
will increase the size of .bss section of ACRN binary.

Bootloaders could run into a situation where they cannot
find enough contiguous space to load ACRN binary under 4GB,
which is typically heavily fragmented with E820 types Reserved,
ACPI data, 32-bit PCI hole etc.

This patch does the following
1) Works only for "direct" mode of vboot
2) reserves space for 4K pages of EPT, after boot by parsing
platform E820 table, for all types of VMs.

Size comparison:

w/o patch
Size of DRAM            Size of .bss
48 GB                   0xe1bbc98 (~226 MB)
128 GB                  0x222abc98 (~548 MB)

w/ patch
Size of DRAM            Size of .bss
48 GB                   0x1991c98 (~26 MB)
128 GB                  0x1a81c98 (~28 MB)

Tracked-On: #4563
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-04-01 21:13:37 +08:00
Victor Sun
a68f655a11 HV: update ept address range for pre-launched VM
For a pre-launched VM, a region from PTDEV_HI_MMIO_START is used to store
64bit vBARs of PT devices which address is high than 4G. The region should
be located after all user memory space and be coverd by guest EPT address.

Tracked-On: #4458

Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-03-12 14:56:34 +08:00
Victor Sun
4c0965d89e HV: correct ept page array usage
Currently ept_pages_info[] is initialized with first element only that force
VM of id 0 using SOS EPT pages. This is incorrect for logical partition and
hybrid scenario. Considering SOS_RAM_SIZE and UOS_RAM_SIZE are configured
separately, we should use different ept pages accordingly.

So, the PRE_VM_NUM/SOS_VM_NUM and MAX_POST_VM_NUM macros are introduced to
resolve this issue. The macros would be generated by acrn-config tool when
user configure ACRN for their specific scenario.

One more thing, that when UOS_RAM_SIZE is less then 2GB, the EPT address
range should be (4G + PLATFORM_HI_MMIO_SIZE).

Tracked-On: #4458

Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-03-12 14:56:34 +08:00
Binbin Wu
3d412266bc hv: ept: build 4KB page mapping in EPT for RTVM for MCE on PSC
Deterministic is important for RTVM. The mitigation for MCE on
Page Size Change converts a large page to 4KB pages runtimely during
the vmexit triggered by the instruction fetch in the large page.
These vmexits increase nondeterminacy, which should be avoided for RTVM.
This patch builds 4KB page mapping in EPT for RTVM to avoid these vmexits.

Tracked-On: #4101
Signed-off-by: Binbin Wu <binbin.wu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2019-12-03 09:17:04 +08:00
Binbin Wu
192859ee02 hv: ept: apply MCE on page size change mitigation conditionally
Only apply the software workaround on the models that might be
affected by MCE on page size change. For these models that are
known immune to the issue, the mitigation is turned off.

Atom processors are not afftected by the issue.
Also check the CPUID & MSR to check whether the model is immune to the issue:
CPU is not vulnerable when both CPUID.(EAX=07H,ECX=0H).EDX[29] and
IA32_ARCH_CAPABILITIES[IF_PSCHANGE_MC_NO] are 1.

Other cases not listed above, CPU may be vulnerable.

This patch also changes MACROs for MSR IA32_ARCH_CAPABILITIES bits to UL instead of U
since the MSR is 64bit.

Tracked-On: #4101
Signed-off-by: Binbin Wu <binbin.wu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2019-12-03 09:17:04 +08:00
Binbin Wu
fa3888c12a hv: ept: disable execute right on large pages
Issue description:
-----------------
Machine Check Error on Page Size Change
Instruction fetch may cause machine check error if page size
and memory type was changed without invalidation on some
processors[1][2]. Malicious guest kernel could trigger this issue.

This issue applies to both primary page table and extended page
tables (EPT), however the primary page table is controlled by
hypervisor only. This patch mitigates the situation in EPT.

Mitigation details:
------------------
Implement non-execute huge pages in EPT.
This patch series clears the execute permission (bit 2) in the
EPT entries for large pages. When EPT violation is triggered by
guest instruction fetch, hypervisor converts the large page to
smaller 4 KB pages and restore the execute permission, and then
re-execute the guest instruction.

The current patch turns on the mitigation by default.
The follow-up patches will conditionally turn on/off the feature
per processor model.

[1] Refer to erratum KBL002 in "7th Generation Intel Processor
Family and 8th Generation Intel Processor Family for U Quad Core
Platforms Specification Update"
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/7th-gen-core-family-spec-update.pdf
[2] Refer to erratum SKL002 in "6th Generation Intel Processor
Family Specification Update"
https://www.intel.com/content/www/us/en/products/docs/processors/core/desktop-6th-gen-core-family-spec-update.html

Tracked-On: #4101
Signed-off-by: Binbin Wu <binbin.wu@intel.com>
Reviewed-by: Eddie Dong <eddie.dong@intel.com>
2019-11-13 08:00:36 +08:00
Mingqiang Chi
d81872ba18 hv:Change the function parameter for init_ept_mem_ops
Currently the parameter of init_ept_mem_ops is
'struct acrn_vm *vm' for this api,change it to
'struct memory_ops *mem_ops' and 'vm_id' to avoid
the reversed dependency, page.c is hardware layer and vm structure
is its upper-layer stuff.

Tracked-On: #1842
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Reviewed-by: Eddie Dong <eddie.dong@intel.com>
2019-10-23 12:48:30 +08:00
Binbin Wu
5c81659713 hv: ept: flush cache for modified ept entries
EPT tables are shared by MMU and IOMMU.
Some IOMMUs don't support page-walk coherency, the cpu cache of EPT entires
should be flushed to memory after modifications, so that the modifications
are visible to the IOMMUs.

This patch adds a new interface to flush the cache of modified EPT entires.
There are different implementations for EPT/PPT entries:
- For PPT, there is no need to flush the cpu cache after update.
- For EPT, need to call iommu_flush_cache to make the modifications visible
to IOMMUs.

Tracked-On: #3607
Signed-off-by: Binbin Wu <binbin.wu@intel.com>
Reviewed-by: Anthony Xu <anthony.xu@intel.com>
2019-08-26 10:47:17 +08:00
Mingqiang Chi
bd1e7a46b3 hv:cleanup header files for arch folder
cleanup arch folder, only include some necessary,
doesn't include hypervisor.h

Tracked-On: #1842
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>

	modified:   arch/x86/configs/apl-mrb/pt_dev.c
	modified:   arch/x86/configs/apl-mrb/ve820.c
	modified:   arch/x86/configs/dnv-cb2/pt_dev.c
	modified:   arch/x86/configs/dnv-cb2/ve820.c
	modified:   arch/x86/configs/partition_config.c
	modified:   arch/x86/configs/sharing_config.c
	modified:   arch/x86/cpu.c
	modified:   arch/x86/cpu_state_tbl.c
	modified:   arch/x86/e820.c
	modified:   arch/x86/gdt.c
	modified:   arch/x86/init.c
	modified:   arch/x86/ioapic.c
	modified:   arch/x86/irq.c
	modified:   arch/x86/lapic.c
	modified:   arch/x86/mmu.c
	modified:   arch/x86/notify.c
	modified:   arch/x86/page.c
	modified:   arch/x86/pagetable.c
	modified:   arch/x86/static_checks.c
	modified:   arch/x86/timer.c
	modified:   arch/x86/trampoline.c
	modified:   arch/x86/vmx.c
	modified:   arch/x86/vtd.c
	modified:   boot/include/acpi.h
	modified:   include/arch/x86/e820.h
	modified:   include/arch/x86/ioapic.h
2019-02-22 13:14:36 +08:00
Victor Sun
49e6deaf26 HV: rename the term of vm0 to sos vm
Under sharing mode, VM0 is identical with SOS VM. But the coupling of
SOS VM and VM 0 is not friendly for partition mode.

This patch is a pure term change of vm0 to sos VM, it does not change
any code logic or senmantic.

Tracked-On: #2291

Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2019-01-21 18:03:31 +08:00
Li, Fei1
ae9d4361fd hv: minimize the case of "identifier reuse"
Identifier reuse may arise confusion. So should minimize the case of it
as much as possible. This patch is try to do this except the PCI related
module.

Tracked-On: #861
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
2018-12-07 15:21:39 +08:00
Shiqing Gao
f73cf21187 hv: fix 'Unused procedure parameter'
remove the unused procedure parameter

Tracked-On: #861
Signed-off-by: Shiqing Gao <shiqing.gao@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2018-12-04 18:28:32 +08:00
Li, Fei1
bd1c0838d1 hv: trusty: reserve memory for trusty
The previous would reserve memory for trusty in SOS kernel. Howerer,
there would no available 16 MB continue memory any more after a long time.
This result in allocating memory for trusty failed. This patch will reserve
memory for trusty in ACRN hypervisor in which case the memory allocation
for trusty will never fail.

Tracked-On: #1942
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
2018-11-30 16:49:27 +08:00
Xiangyang Wu
99586e32cc HV:treewide:rename vm data structure
For data structure types "struct vm", its name is identical
with variable name in the same scope. This is a MISRA C  violation.

Naming convention rule:If the data structure type is used by multi
modules, its corresponding logic resource is exposed to external
components (such as SOS, UOS), and its name meaning is simplistic
(such as vcpu, vm), its name needs prefix "acrn_".

The following udpates are made:
struct vm *vm-->struct acrn_vm *vm

Tracked-On: #861

Signed-off-by: Xiangyang Wu <xiangyang.wu@linux.intel.com>
2018-11-05 15:35:49 +08:00
Li, Fei1
ed113f570f hv: mmu: remove "##" for MISRA C
In the C99 standard, the order of evaluation associated with multiple #,
multiple ## or a mix of # and ## preprocessor operator is unspecifie.
 So it is unsafe to use multiple # or ## in a macro.

Tracked-On: #861
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
2018-11-02 13:15:48 +08:00
Li, Fei1
541f3713d2 hv: bug fix: normal world may get trusty world's pdpt page
Normal world would also setup 511 GB gpa EPT mapping when initialize.
So we couldn't know which the world is from the gpa. But trusty is so
special for that we know where it would get a pml4_page or pdpt_page.
As a result, we could simpler this by just return the pml4_page or
pdpt_page to it when it needs.

Tracked-On: #861
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
2018-11-02 13:15:48 +08:00
Li, Fei1
0391f84c83 hv: mmu: replace dynamic memory allocation in memory
Replace dynamic memory allocation in memory management with static memory allocation.
Since the static memory allocation can guarantee the allocation never failed, so
split_large_page and construct_pgentry don't need to return a errno any more.
Besides, the destroy_ept don't need to free page any more. Instead, it would memset
the eptp to 0 to make sure we can't walk this paging table again.

Tracked-On: #861
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
2018-11-02 13:15:48 +08:00
Li, Fei1
9c7c0de08f hv: mmu: add static paging table allocation for EPT
Add static paging table allocation API for EPT.
Note: must configure SOS/UOS_REAM_SIZE exactly as the platform.

Tracked-On: #861
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
2018-11-02 13:15:48 +08:00
Li, Fei1
dc9d18a868 hv: mmu: add static paging table allocation for hypervisor
Add static paging table allocation API for hypervisor.
Note: must configure PLATFORM_RAM_SIZE and PLATFORM_MMIO_SIZE exactly as the platform.

Rename RAM_START/RAM_SIZE to HV_RAM_START/HV_RAM_SIZE for HV.

Tracked-On: #861
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
2018-11-02 13:15:48 +08:00