2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-11 19:50:04 -07:00
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x86/hyperv: Change vTOM handling to use standard coco mechanisms
Hyper-V guests on AMD SEV-SNP hardware have the option of using the
"virtual Top Of Memory" (vTOM) feature specified by the SEV-SNP
architecture. With vTOM, shared vs. private memory accesses are
controlled by splitting the guest physical address space into two
halves.
vTOM is the dividing line where the uppermost bit of the physical
address space is set; e.g., with 47 bits of guest physical address
space, vTOM is 0x400000000000 (bit 46 is set). Guest physical memory is
accessible at two parallel physical addresses -- one below vTOM and one
above vTOM. Accesses below vTOM are private (encrypted) while accesses
above vTOM are shared (decrypted). In this sense, vTOM is like the
GPA.SHARED bit in Intel TDX.
Support for Hyper-V guests using vTOM was added to the Linux kernel in
two patch sets[1][2]. This support treats the vTOM bit as part of
the physical address. For accessing shared (decrypted) memory, these
patch sets create a second kernel virtual mapping that maps to physical
addresses above vTOM.
A better approach is to treat the vTOM bit as a protection flag, not
as part of the physical address. This new approach is like the approach
for the GPA.SHARED bit in Intel TDX. Rather than creating a second kernel
virtual mapping, the existing mapping is updated using recently added
coco mechanisms.
When memory is changed between private and shared using
set_memory_decrypted() and set_memory_encrypted(), the PTEs for the
existing kernel mapping are changed to add or remove the vTOM bit in the
guest physical address, just as with TDX. The hypercalls to change the
memory status on the host side are made using the existing callback
mechanism. Everything just works, with a minor tweak to map the IO-APIC
to use private accesses.
To accomplish the switch in approach, the following must be done:
* Update Hyper-V initialization to set the cc_mask based on vTOM
and do other coco initialization.
* Update physical_mask so the vTOM bit is no longer treated as part
of the physical address
* Remove CC_VENDOR_HYPERV and merge the associated vTOM functionality
under CC_VENDOR_AMD. Update cc_mkenc() and cc_mkdec() to set/clear
the vTOM bit as a protection flag.
* Code already exists to make hypercalls to inform Hyper-V about pages
changing between shared and private. Update this code to run as a
callback from __set_memory_enc_pgtable().
* Remove the Hyper-V special case from __set_memory_enc_dec()
* Remove the Hyper-V specific call to swiotlb_update_mem_attributes()
since mem_encrypt_init() will now do it.
* Add a Hyper-V specific implementation of the is_private_mmio()
callback that returns true for the IO-APIC and vTPM MMIO addresses
[1] https://lore.kernel.org/all/20211025122116.264793-1-ltykernel@gmail.com/
[2] https://lore.kernel.org/all/20211213071407.314309-1-ltykernel@gmail.com/
[ bp: Touchups. ]
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/1679838727-87310-7-git-send-email-mikelley@microsoft.com
2023-03-26 06:52:01 -07:00
|
|
|
|
|
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
2021-03-23 18:47:16 +00:00
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-22 21:28:40 +02:00
|
|
|
|
2023-08-18 06:29:11 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-25 08:21:07 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-18 06:29:11 -04:00
|
|
|
|
2021-10-25 08:21:07 -04:00
|
|
|
|
|
|
|
|
|
2023-08-18 06:29:11 -04:00
|
|
|
|
2021-10-25 08:21:07 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
2023-01-02 07:12:51 +00:00
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
2021-12-27 19:31:54 -08:00
|
|
|
|
|
|
|
|
|
2021-07-14 11:34:45 -07:00
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
2023-08-24 01:07:11 -07:00
|
|
|
|
2023-08-24 01:07:03 -07:00
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
2021-04-16 17:43:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-16 17:43:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-16 17:43:03 -07:00
|
|
|
|
2021-04-16 17:43:02 -07:00
|
|
|
|
|
|
|
|
|
2021-04-16 17:43:03 -07:00
|
|
|
|
2021-04-16 17:43:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
2022-09-28 14:40:46 +08:00
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
2022-09-28 14:40:46 +08:00
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
2022-09-28 14:40:46 +08:00
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-02 13:38:15 -08:00
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-02 13:38:18 -08:00
|
|
|
|
|
|
|
|
|
2021-03-10 10:47:49 -08:00
|
|
|
|
|
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-14 12:45:04 -07:00
|
|
|
|
2021-03-02 13:38:18 -08:00
|
|
|
|
2020-08-14 12:45:04 -07:00
|
|
|
|
2021-07-14 11:34:45 -07:00
|
|
|
|
|
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-13 17:01:46 -07:00
|
|
|
|
|
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-14 11:34:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-02 13:38:13 -08:00
|
|
|
|
|
|
|
|
|
2023-06-23 15:09:49 -07:00
|
|
|
|
2021-03-02 13:38:13 -08:00
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-10 18:57:13 +00:00
|
|
|
|
|
|
|
|
|
2023-03-27 06:16:06 -07:00
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
2022-11-01 15:53:52 +01:00
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
2022-11-01 15:53:52 +01:00
|
|
|
|
|
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-01 15:53:52 +01:00
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-27 06:16:06 -07:00
|
|
|
|
2021-09-10 18:57:13 +00:00
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-01 15:53:52 +01:00
|
|
|
|
|
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-27 06:16:06 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-10 18:57:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-27 06:16:06 -07:00
|
|
|
|
2021-09-10 18:57:13 +00:00
|
|
|
|
|
|
|
|
|
2023-03-27 06:16:06 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-10 18:57:13 +00:00
|
|
|
|
2023-03-27 06:16:06 -07:00
|
|
|
|
2021-09-10 18:57:13 +00:00
|
|
|
|
|
|
|
|
|
2020-04-06 08:53:31 -07:00
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
x86/hyperv: Implement hv_is_hibernation_supported()
The API will be used by the hv_balloon and hv_vmbus drivers.
Balloon up/down and hot-add of memory must not be active if the user
wants the Linux VM to support hibernation, because they are incompatible
with hibernation according to Hyper-V team, e.g. upon suspend the
balloon VSP doesn't save any info about the ballooned-out pages (if any);
so, after Linux resumes, Linux balloon VSC expects that the VSP will
return the pages if Linux is under memory pressure, but the VSP will
never do that, since the VSP thinks it never stole the pages from the VM.
So, if the user wants Linux VM to support hibernation, Linux must forbid
balloon up/down and hot-add, and the only functionality of the balloon VSC
driver is reporting the VM's memory pressure to the host.
Ideally, when Linux detects that the user wants it to support hibernation,
the balloon VSC should tell the VSP that it does not support ballooning
and hot-add. However, the current version of the VSP requires the VSC
should support these capabilities, otherwise the capability negotiation
fails and the VSC can not load at all, so with the later changes to the
VSC driver, Linux VM still reports to the VSP that the VSC supports these
capabilities, but the VSC ignores the VSP's requests of balloon up/down
and hot add, and reports an error to the VSP, when applicable. BTW, in
the future the balloon VSP driver will allow the VSC to not support the
capabilities of balloon up/down and hot add.
The ACPI S4 state is not a must for hibernation to work, because Linux is
able to hibernate as long as the system can shut down. However in practice
we decide to artificially use the presence of the virtual ACPI S4 state as
an indicator of the user's intent of using hibernation, because Linux VM
must find a way to know if the user wants to use the hibernation feature
or not.
By default, Hyper-V does not enable the virtual ACPI S4 state; on recent
Hyper-V hosts (e.g. RS5, 19H1), the administrator is able to enable the
state for a VM by WMI commands.
Once all the vmbus and VSC patches for the hibernation feature are
accepted, an extra patch will be submitted to forbid hibernation if the
virtual ACPI S4 state is absent, i.e. hv_is_hibernation_supported() is
false.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-19 23:16:04 -08:00
|
|
|
|
2021-02-01 15:48:11 +01:00
|
|
|
|
|
|
|
|
|
2021-10-25 08:21:06 -04:00
|
|
|
|
2021-10-25 08:21:12 -04:00
|
|
|
|
2023-08-24 01:07:04 -07:00
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
2021-03-23 18:47:16 +00:00
|
|
|
|
2022-03-24 09:14:51 -07:00
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
x86/hyperv: Implement hv_is_hibernation_supported()
The API will be used by the hv_balloon and hv_vmbus drivers.
Balloon up/down and hot-add of memory must not be active if the user
wants the Linux VM to support hibernation, because they are incompatible
with hibernation according to Hyper-V team, e.g. upon suspend the
balloon VSP doesn't save any info about the ballooned-out pages (if any);
so, after Linux resumes, Linux balloon VSC expects that the VSP will
return the pages if Linux is under memory pressure, but the VSP will
never do that, since the VSP thinks it never stole the pages from the VM.
So, if the user wants Linux VM to support hibernation, Linux must forbid
balloon up/down and hot-add, and the only functionality of the balloon VSC
driver is reporting the VM's memory pressure to the host.
Ideally, when Linux detects that the user wants it to support hibernation,
the balloon VSC should tell the VSP that it does not support ballooning
and hot-add. However, the current version of the VSP requires the VSC
should support these capabilities, otherwise the capability negotiation
fails and the VSC can not load at all, so with the later changes to the
VSC driver, Linux VM still reports to the VSP that the VSC supports these
capabilities, but the VSC ignores the VSP's requests of balloon up/down
and hot add, and reports an error to the VSP, when applicable. BTW, in
the future the balloon VSP driver will allow the VSC to not support the
capabilities of balloon up/down and hot add.
The ACPI S4 state is not a must for hibernation to work, because Linux is
able to hibernate as long as the system can shut down. However in practice
we decide to artificially use the presence of the virtual ACPI S4 state as
an indicator of the user's intent of using hibernation, because Linux VM
must find a way to know if the user wants to use the hibernation feature
or not.
By default, Hyper-V does not enable the virtual ACPI S4 state; on recent
Hyper-V hosts (e.g. RS5, 19H1), the administrator is able to enable the
state for a VM by WMI commands.
Once all the vmbus and VSC patches for the hibernation feature are
accepted, an extra patch will be submitted to forbid hibernation if the
virtual ACPI S4 state is absent, i.e. hv_is_hibernation_supported() is
false.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-19 23:16:04 -08:00
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
2021-10-25 08:21:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-05-30 00:14:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|