Upstream: no
For memory encrypted guest, its pages' encrypt status will changed at
runtime. When user reboot the guest, the pages' encrypt status during
last boot were ignored. So during the boot flow of reboot, there may
be 2 versions of memory data lies in cache as follows:
+--------+ | |
| | +--------------+ --+
| | | | \
|________| | | \
cacheline for -> |________| <-+ | | \
pa1(c=0) | | \ |______________| \
| | \_ 64 bytes aligned <- pa1 \
| | _ |______________| 4K
| | / | | page
cacheline for |________| / | | /
pa1(c=1) -> |________| <-+ | | /
| | | | /
| | | | /
| | | | /
| | +--------------+ --+
| | | |
If the older version cache was flushed after that of newer version, and
guest read the memory again, then it will get corrupted data and may
lead to crash.
In this change, for any memory encrypted guest, the cache is forcibly
flushed to memory before the next boot flow, which ensures that memory
access is up-to-date.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
Currently, reboot a CSV2 guest is unsupported because vCPU state is
encrypted and can't be initialized when guest reboots to execute
OVMF code.
In order to support reboot a CSV2 guest, make a backup of the
encrypted VMSA before booting the guest, and restore VMSA from the
backup before rebooting the guest.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
In the upcoming patches, we will support for rebooting CSV2 guests. In
order to support rebooting CSV2 guest, we will set
vcpu->arch.guest_state_protected to false, before VMRUN, so that VMM
can initialize vCPU states and VMSA, and then set
vcpu->arch.guest_state_protected back to true to bypass unexpected
behaviour in KVM. Besides, cache flush is necessary during rebooting a
memory encrypted guest.
Introduce control_{pre,post}_system_reset ioctl interfaces to support
rebooting memory encrypted guests correctly.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
VMCB.control.ghcb_gpa contains necessary info to support runtime CSV2
guest. At present, it includes the following points:
1. For GHCB MSR protocol, ghcb_gpa stores the negotiation result
2. For GHCB page protocol, ghcb_gpa stores the GPA of GHCB page
In addition, AP VCPU's SIPI state and GHCB page mapping state are
temporarily stored in KVM.
When CSV2 guest was migrated to the recipient, KVM needs to restore
VMCB.control.ghcb_gpa, VCPU's SIPI state and GHCB page mapping state on
the source side.
This patch is to support export MSR_AMD64_SEV_ES_GHCB to userspace. KVM
can collect all the infos dictated above and return to userspace if
userspace request to get MSR_AMD64_SEV_ES_GHCB, and KVM can restore all
the infos dictated above if userspace request to set
MSR_AMD64_SEV_ES_GHCB.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
When migrate CSV2 guest to the recipient, the KVM which on
recipient's side needs to update the guest context so that the guest
can continues to run. The control register state is necessary for
updating the guest context.
Allows the control registers to be updated in __set_sregs() so that
the CSV2 guest could continue running correctly after migrated to
the recipient.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
1. support sm2 on 4th cpu
2. create new ccp-dev-v5.c file for hygon ccp only
3. restore original ccp-dev-v5.c file
Signed-off-by: yangdepei <yangdepei@hygon.cn>
Upstream: no
The command is used for copying the incoming buffer into the VMSA
memory regions of CSV2 guest.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
The command is used for encrypting the VCPU register states of CSV2
guest using the encryption context created with KVM_SEV_SEND_START.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
The current definition of struct sev_data_send_update_vmsa in
include/linux/psp-sev.h does not comply with SEV API spec.
Fix it here.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
The existing kernel supports only interrupt for the mailbox interface
for X86 sending commands to PSP and PSP to ack, e.g. the SEV commands.
However, some PSP-based security modules in Hygon CPU, such as TPCM
and TDM(Trusted Dynamic Measuring), needs sending
commands/notifications proactively to X86 core via interrupt and a 2nd
mailbox interface. Similar to the existing one, the 2nd mailbox
consists of a 32-bits command register and two 32-bits data registers.
The PSP interrupt handling needs to add this interrupt support;
besides, in order to support user defined command handler, a callback
registration function is also provided. Up to 16 command callbacks is
supported, which are indexed by command IDs. Currently, command ID 0
is assigned to TPCM and 1 to TDM, while others are reserved.
Currently, Hygon PSP does not support bootloader info reg, remove
the value of bootloader_info_reg.
Signed-off-by: chench <chench@hygon.cn>
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
HYGON's fTPM and TDM need to send commands to PSP to complete the
firmware function.
In order to be compatible with the original kernel code, The command
of psp_do_cmd is added to send the command from x86 to PSP. The
interface is currently used for fTPM/TDM/TPCM of HYGON.
Signed-off-by: chench <chench@hygon.cn>
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
When KVM_CSV_COMMAND_BATCH handling a batch of RECEIVE_UPDATE_DATA
commands, it need execute 2 steps:
1. Enqueue each SEND_UPDATE_DATA command data to CSV RING_BUFFER
queues (as input of RING_BUFFER command)
2. Issue RING_BUFFER command
In this change, we add sev_receive_update_data_to_ringbuf() to
prepare input required by RING_BUFFER command as dictated in step 1.
Signed-off-by: fangbaoshun <fangbaoshun@hygon.cn>
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
When KVM_CSV_COMMAND_BATCH handling a batch of SEND_UPDATE_DATA
commands, it need execute 3 steps:
1. Enqueue each SEND_UPDATE_DATA command data to CSV RING_BUFFER
queues (as input of RING_BUFFER command)
2. Issue RING_BUFFER command
3. Copy the output of RING_BUFFER command to userspace
In this change, we add sev_send_update_data_to_ringbuf() to prepare
input required by RING_BUFFER command as dictated in step 1, and
add sev_send_update_data_copy_to_user() to copy output userspace as
dictated in step 3.
Signed-off-by: fangbaoshun <fangbaoshun@hygon.cn>
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
In the upcoming patches, many buffers need to be allocated in
KVM_CSV_COMMAND_BATCH code paths. To avoid memory allocation
failures, directly allocate a memory pool in sev_hardware_setup()
and free the memory pool in sev_hardware_teardown().
When KVM_CSV_COMMAND_BATCH handling a batch of
SEND_UPDATE_DATA/RECEIVE_UPDATE_DATA commands, it will allocate
trans buffers from the memory pool.
Signed-off-by: fangbaoshun <fangbaoshun@hygon.cn>
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
The API KVM_CSV_COMMAD_BATCH receives data of structure
kvm_csv_command_batch which embedded a link list of CSV command
requests from userspace. It will do some preparation works to ensure
data available for CSV RING_BUFFER mode, and then issues
RING_BUFFER command.
Signed-off-by: fangbaoshun <fangbaoshun@hygon.cn>
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
The CSV firmware stays in Mailbox mode by default. Upon successfully
switched to CSV RING_BUFFER mode, the semantics of the 3 registers
used for communicate between X86 and CSV firmware will be changed:
- The CmdResp register becomes the RBCtl register. It is only
ever written by X86.
- The CmdBufAddr_Hi register becomes the RBTail register. It
is only ever written by X86.
- The CmdBufAddr_Lo register becomes the RBHead register. It
should never be written by X86; the PSP will update it.
The CSV firmware will exit CSV RING_BUFFER mode when it read invalid
value from the RBCtl register.
Signed-off-by: fangbaoshun <fangbaoshun@hygon.cn>
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
Invoke RING_BUFFER command will switch CSV firmware to RING_BUFFER
mode. When CSV firmware stays in RING_BUFFER mode, it will fetch
commands from CSV RING_BUFFER queues which are filled by X86.
The CSV firmware will exit RING_BUFFER mode after SHUTDOWN command
is completed.
Signed-off-by: fangbaoshun <fangbaoshun@hygon.cn>
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
In CSV RING_BUFFER mode, X86 will dequeue status entries written by
PSP after the corresponding command has been handled.
Signed-off-by: fangbaoshun <fangbaoshun@hygon.cn>
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
In CSV RING_BUFFER mode, X86 will enqueue command pointers to the sub-queue
which stores the command pointers. The priority will be given through
parameter.
Signed-off-by: fangbaoshun <fangbaoshun@hygon.cn>
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
There are up to two queues created in RING_BUFFER mode, each with two
sub-queues. The sub-queues store the command pointer entries (written
only by the x86) and status entries (written only by the CSV Firmware)
respectively. The two queues are low priority queue (required) and
high priority queue (optional) respectively.
In this change, we introduce csv_ring_buffer_queue_init() to
initialize CSV RING_BUFFER queues, and csv_ring_buffer_queue_free()
to cleanup CSV RING_BUFFER queues.
Signed-off-by: fangbaoshun <fangbaoshun@hygon.cn>
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
The CSV_DOWNLOAD_FIRMWARE command can be used by the platform owner to
updating CSV firmware.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
The CSV_PLATFORM_SHUTDOWN command can be used by the platform owner to
switch platform to PSTATE.UNINIT.
The DOWNLOAD_FIRMWARE API can only performed when platform is in the
PSTATE.UNINIT. In order to support DOWNLOAD_FIRMWARE at userspace, we
need invoke PLATFORM_SHUTDOWN before that.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
The CSV_PLATFORM_INIT command can be used by the platform owner to
switch platform from PSTATE.UNINIT to PSTATE.INIT.
In the upcoming patches, we'll support DOWNLOAD_FIRMWARE at userspace.
Due to DOWNLOAD_FIRMWARE can only performed when platform is in the
PSTATE.UNINIT, we need invoke PLATFORM_INIT following DOWNLOAD_FIRMWARE
to switch platform back to PSTATE.INIT.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
When ccp driver detect CSV support on Hygon CPU, it should try to
update the latest CSV firmware on the system paths.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
CSV firmware provides the guest a mechanism to communicate with
the PSP without risk from a malicious hypervisor who wishes to read,
alter, drop or replay the messages sent. The driver provides
userspace interface to communicate with the PSP to request the
attestation report and more.
Signed-off-by: fangbaoshun <fangbaoshun@hygon.cn>
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
When sev guest wants to collect the attestation report, it cannot directly
communicate with psp. Add VM_ATTESTATION hypercall to allow sev guest to
tell host to help get the attestation report. Since sev guest memory is
encrypted, host cannot tamper with the report data.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
The commit 08f253ec37 ("x86/cpu: Clear SME feature flag when not in
use") will clear SME feature flag if the kernel is not using it on AMD
CPUs, this will help userspace to determine if SME is available and in
use from /proc/cpuinfo.
Apply this change to Hygon CPUs as well.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
Add CPU feature detection for Hygon 3rd CSV. This feature enhances
CSV2 by also isolating NPT and VMCB, making them in-accessible to
the hypervisor.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
This is a pure feature bits leaf. Add SM3 and SM4 feature bits from
this leaf on Hygon CPUs.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
Hygon SME is identified by CPUID 0x8000001f, but requires BIOS support
to enable it (set bit 23 of MSR_AMD64_SYSCFG). Hygon CSV and CSV2 are
identified by CPUID 0x8000001f, but requires BIOS support to enable it
(set bit 23 of MSR_AMD64_SYSCFG and set bit 0 of MSR_K7_HWCR). Only show
the SME, CSV, CSV2 features as available if reported by CPUID and
enabled by BIOS.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
The KVM will print 'SEV supported' instead of 'CSV supported' on Hygon
CPU if CSV is supported. Fix these confused messages here.
Fix other 'SEV' messages in arch/x86/kvm/svm/svm.c.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
The Cryptographic Co-Processor module will print 'SEV API' instead of
'CSV API' on Hygon CPU if CSV is supported. Fix this confused message
here.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
Add CSV and CSV2 to the list of memory encryption features. Also
print CPU vendor while printing CSV infos.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
Provide CONFIG_HYGON_CSV to the arch/x86/Kconfig, and build HYGON's
specific memory encryption support into the kernel when
CONFIG_HYGON_CSV=y.
Besides, add arch/x86/include/asm/processor-hygon.h to contains
helpers to determine the Hygon CPUs so that we can call functions
specific to CSV in the native code and reduce code intruision.
Signed-off-by: hanliyang <hanliyang@hygon.cn>
Upstream: no
Since Hygon 4th CPUs, there are new Secure Processor devices with 3
different PCI device IDs, add them in the device list.
Signed-off-by: Xin Jiang <jiangxin@hygon.cn>
Signed-off-by: hanliyang <hanliyang@hygon.cn>
driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I96KNQ
CVE: NA
----------------------------------------------------------------------
We found that the second parameter of function ata_wait_after_reset() is
incorrectly used. We call smp_ata_check_ready_type() to poll the device
type until the 30s timeout, so the correct deadline should be (jiffies +
30000).
Fixes: 3c2673a09c ("scsi: hisi_sas: Fix SATA devices missing issue during I_T nexus reset")
Signed-off-by: xiabing <xiabing12@h-partners.com>
Signed-off-by: Yihang Li <liyihang9@huawei.com>
Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: Bing Xia <xiabing12@h-partners.com>
Signed-off-by: chenyi <chenyi211@huawei.com>
mainline inclusion
from mainline-v6.9-rc1
commit f9242f166770b681d9f71341d96adc01c4da00ef
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I96KNQ
CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f9242f166770b681d9f71341d96adc01c4da00ef
----------------------------------------------------------------------
hisi_hba->timer is not used for v3 hw but there are two places that some
operations related to hisi_hba->timer are called by v3 hw:
- Deleting the timer in function hisi_sas_v3_hw() which is only for v3 hw;
- Deleting the timer in function hisi_sas_controller_reset_prepare() which
is common for v1/v2/v3 hw.
We can remove the timer in the first case, but for the second scenario we
need to remove it only for v3 hw, so check hw->sht which is NULL only for
v3 hw before deleting hisi_hba->timer.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Link: https://lore.kernel.org/r/1705904747-62186-5-git-send-email-chenxiang66@hisilicon.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Bing Xia <xiabing12@h-partners.com>
Signed-off-by: chenyi <chenyi211@huawei.com>
chinaljp030