- Oct 29, 2020
-
-
Pu Wen authored
commit 24beb83a upstream. The Hygon Dhyana CPU has the SMBus device with PCI device ID 0x790b, which is the same as AMD CZ SMBus device. So add Hygon Dhyana support to the i2c-piix4 driver by using the code path of AMD. Signed-off-by:
Pu Wen <puwen@hygon.cn> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit e0ceeae7 upstream. The Hygon family 18h multi-die processor platform supports 1, 2 or 4-Dies per socket. The topology looks like this: System View (with 1-Die 2-Socket): |------------| ------ ----- SOCKET0 | D0 | | D1 | SOCKET1 ------ ----- System View (with 2-Die 2-socket): -------------------- | -------------|------ | | | | ------------ ------------ SOCKET0 | D1 -- D0 | | D3 -- D2 | SOCKET1 ------------ ------------ System View (with 4-Die 2-Socket) : -------------------- | -------------|------ | | | | ------------ ------------ | D1 -- D0 | | D7 -- D6 | | | \/ | | | | \/ | | SOCKET0 | | /\ | | | | /\ | | SOCKET1 | D2 -- D3 | | D4 -- D5 | ------------ ------------ | | | | ------|------------| | -------------------- Currently phys_proc_id = initial_apicid >> bits calculates the physical processor ID from the initial_apicid by shifting *bits*. However, this does not work for 1-Die and 2-Die 2-socket systems. According to document [1] section 2.1.11.1, the bits is the value of CPUID_Fn80000008_ECX[12:15]. The possible values are 4, 5 or 6 which mean: 4 - 1 die 5 - 2 dies 6 - 3/4 dies. Hygon programs the initial ApicId the same way as AMD. The ApicId is read from CPUID_Fn00000001_EBX (see section 2.1.11.1 of referrence [1]) and the definition is as below (see section 2.1.10.2.1.3 of [1]): ------------------------------------------------- Bit | 6 | 5 4 | 3 | 2 1 0 | |-----------|---------|--------|----------------| IDs | Socket ID | Node ID | CCX ID | Core/Thread ID | ------------------------------------------------- So for 3/4-Die configurations, the bits variable is 6, which is the same as the ApicID definition field. For 1-Die and 2-Die configurations, bits is 4 or 5, which will cause the right shifted result to not be exactly the value of socket ID. However, the socket ID should be obtained from ApicId[6]. To fix the problem and match the ApicID field definition, set the shift bits to 6 for all Hygon family 18h multi-die CPUs. Because AMD doesn't have 2-Socket systems with 1-Die/2-Die processors (see reference [2]), this doesn't need to be changed on the AMD side but only for Hygon. References: [1] https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf [2] https://www.amd.com/en/products/specifications/processors [bp: heavily massage commit message. ] Signed-off-by:
Pu Wen <puwen@hygon.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Thomas Lendacky <Thomas.Lendacky@amd.com> Cc: Yazen Ghannam <yazen.ghannam@amd.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/1553355740-19999-1-git-send-email-puwen@hygon.cn Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit d93217d8 upstream. Add support for Hygon Dhyana family 18h processor for k10temp to get the temperature. As Hygon Dhyana shares the same function interface with AMD family 17h, so add Hygon PCI Vendor ID and reuse the code path of AMD. Signed-off-by:
Pu Wen <puwen@hygon.cn> Acked-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit 995d5f64 upstream. The tool cpupower is useful to get CPU frequency information and monitor power stats on the Hygon Dhyana platform. So add Hygon Dhyana support to it by checking vendor and family to share the code path of AMD family 17h. Signed-off-by:
Pu Wen <puwen@hygon.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Acked-by:
Shuah Khan (Samsung OSG) <shuah@kernel.org> CC: Prarit Bhargava <prarit@redhat.com> CC: Shuah Khan <shuah@kernel.org> CC: Thomas Gleixner <tglx@linutronix.de> CC: Thomas Renninger <trenn@suse.com> CC: linux-pm@vger.kernel.org Link: http://lkml.kernel.org/r/5ce86123a7b9dad925ac583d88d2f921040e859b.1538583282.git.puwen@hygon.cn Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit c4a3e946 upstream. Add support for Hygon Dhyana CPU to EDAC. Signed-off-by:
Pu Wen <puwen@hygon.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: mchehab@kernel.org Cc: tglx@linutronix.de Cc: mingo@redhat.com Cc: hpa@zytor.com Cc: thomas.lendacky@amd.com Cc: linux-edac@vger.kernel.org Link: https://lkml.kernel.org/r/9d71061301177822bc55b3bfd44f91057458d886.1537533369.git.puwen@hygon.cn Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit cc9690cf upstream. The Hygon Dhyana CPU supports ACPI P-States, and there is SMBus device (PCI device ID 0x790b) on the Hygon platform. Add Hygon Dhyana support to the cpufreq driver by using the code path of AMD family 17h. Signed-off-by:
Pu Wen <puwen@hygon.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: rjw@rjwysocki.net Cc: viresh.kumar@linaro.org Cc: bp@alien8.de Cc: tglx@linutronix.de Cc: mingo@redhat.com Cc: hpa@zytor.com Cc: x86@kernel.org Cc: thomas.lendacky@amd.com Cc: rafael@kernel.org Cc: linux-pm@vger.kernel.org Link: https://lkml.kernel.org/r/4db6f0f8537a93c172430c446a0297a6ab1c3c2d.1537533369.git.puwen@hygon.cn Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit 7377ed4b upstream. The Hygon Dhyana CPU has NONSTOP TSC feature, so enable the ACPI driver support to it. Signed-off-by:
Pu Wen <puwen@hygon.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: rjw@rjwysocki.net Cc: tglx@linutronix.de Cc: mingo@redhat.com Cc: hpa@zytor.com Cc: x86@kernel.org Cc: thomas.lendacky@amd.com Cc: lenb@kernel.org Cc: rafael@kernel.org Cc: linux-acpi@vger.kernel.org Link: https://lkml.kernel.org/r/cce6ee26f4e2ebbab493433264d89d7cea661284.1537533369.git.puwen@hygon.cn Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit 40442403 upstream. To make Xen work on the Hygon platform, reuse AMD's Xen support code path for Hygon Dhyana CPU. There are six core performance events counters per thread, so there are six MSRs for these counters. Also there are four legacy PMC MSRs, they are aliases of the counters. In this version, use the legacy and safe version of MSR access. Tested successfully with VPMU enabled in Xen on Hygon platform by testing with perf. Signed-off-by:
Pu Wen <puwen@hygon.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: jgross@suse.com Cc: tglx@linutronix.de Cc: mingo@redhat.com Cc: hpa@zytor.com Cc: x86@kernel.org Cc: thomas.lendacky@amd.com Cc: xen-devel@lists.xenproject.org Link: https://lkml.kernel.org/r/311bf41f08f24550aa6c5da3f1e03a68d3b89dac.1537533369.git.puwen@hygon.cn Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit b8f4abb6 upstream. The Hygon Dhyana CPU has the SVM feature as AMD family 17h does. So enable the KVM infrastructure support to it. Signed-off-by:
Pu Wen <puwen@hygon.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Borislav Petkov <bp@suse.de> Cc: pbonzini@redhat.com Cc: rkrcmar@redhat.com Cc: tglx@linutronix.de Cc: mingo@redhat.com Cc: hpa@zytor.com Cc: x86@kernel.org Cc: thomas.lendacky@amd.com Cc: kvm@vger.kernel.org Link: https://lkml.kernel.org/r/654dd12876149fba9561698eaf9fc15d030301f8.1537533369.git.puwen@hygon.cn Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit ac78bd72 upstream. The machine check architecture for Hygon Dhyana CPU is similar to the AMD family 17h one. Add vendor checking for Hygon Dhyana to share the code path of AMD family 17h. Signed-off-by:
Pu Wen <puwen@hygon.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Borislav Petkov <bp@suse.de> Cc: tglx@linutronix.de Cc: mingo@redhat.com Cc: hpa@zytor.com Cc: tony.luck@intel.com Cc: thomas.lendacky@amd.com Cc: linux-edac@vger.kernel.org Link: https://lkml.kernel.org/r/87d8a4f16bdea0bfe0c0cf2e4a8d2c2a99b1055c.1537533369.git.puwen@hygon.cn Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit 1a576b23 upstream. The Hygon Dhyana CPU has the same speculative execution as AMD family 17h, so share AMD spectre mitigation code with Hygon Dhyana. Also Hygon Dhyana is not affected by meltdown, so add exception for it. [ puwen: Convert Hygon Meltdown mitigation machinery to fit new code. ] Signed-off-by:
Pu Wen <puwen@hygon.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: tglx@linutronix.de Cc: mingo@redhat.com Cc: hpa@zytor.com Cc: x86@kernel.org Cc: thomas.lendacky@amd.com Link: https://lkml.kernel.org/r/0861d39c8a103fc0deca15bafbc85d403666d9ef.1537533369.git.puwen@hygon.cn Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit da33dfef upstream. Add Hygon Dhyana support to the APIC subsystem. When running in 32 bit mode, bigsmp should be enabled if there are more than 8 cores online. Signed-off-by:
Pu Wen <puwen@hygon.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Borislav Petkov <bp@suse.de> Cc: tglx@linutronix.de Cc: mingo@redhat.com Cc: hpa@zytor.com Cc: x86@kernel.org Cc: thomas.lendacky@amd.com Link: https://lkml.kernel.org/r/7a557265a8c7c9e842fe60f9d8e064458801aef3.1537533369.git.puwen@hygon.cn Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit c6babb58 upstream. Hygon's PCI vendor ID is 0x1d94, and there are PCI devices 0x1450/0x1463/0x1464 for the host bridge on the Hygon Dhyana platform. Add Hygon Dhyana support to the PCI and northbridge subsystems by using the code path of AMD family 17h. [ bp: Massage commit message, sort local vars into reverse xmas tree order and move the amd_northbridges.num check up. ] Signed-off-by:
Pu Wen <puwen@hygon.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # pci_ids.h Cc: tglx@linutronix.de Cc: mingo@redhat.com Cc: hpa@zytor.com Cc: x86@kernel.org Cc: thomas.lendacky@amd.com Cc: helgaas@kernel.org Cc: linux-pci@vger.kernel.org Link: https://lkml.kernel.org/r/5f8877bd413f2ea0833378dd5454df0720e1c0df.1537885177.git.puwen@hygon.cn Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit b7a5cb4f upstream. Exit early in functions which are meant to run on AMD only but which get run on different vendor (VMs, etc). [ bp: rewrite commit message. ] Signed-off-by:
Pu Wen <puwen@hygon.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: bhelgaas@google.com Cc: tglx@linutronix.de Cc: mingo@redhat.com Cc: hpa@zytor.com Cc: x86@kernel.org Cc: thomas.lendacky@amd.com Cc: helgaas@kernel.org Link: https://lkml.kernel.org/r/487d8078708baedaf63eb00a82251e228b58f1c2.1537885177.git.puwen@hygon.cn Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit c3fecca4 upstream. The ideal_nops for Hygon Dhyana CPU should be p6_nops. Signed-off-by:
Pu Wen <puwen@hygon.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Borislav Petkov <bp@suse.de> Cc: tglx@linutronix.de Cc: mingo@redhat.com Cc: hpa@zytor.com Cc: x86@kernel.org Cc: thomas.lendacky@amd.com Link: https://lkml.kernel.org/r/79e76c3173716984fe5fdd4a8e2c798bf4193205.1537533369.git.puwen@hygon.cn Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit 6d0ef316 upstream. The PMU architecture for the Hygon Dhyana CPU is similar to the AMD Family 17h one. To support it, call amd_pmu_init() to share the AMD PMU initialization flow, and change the PMU name to "HYGON". The Hygon Dhyana CPU supports both legacy and extension PMC MSRs (perf counter registers and event selection registers), so add Hygon Dhyana support in the similar way as AMD does. Signed-off-by:
Pu Wen <puwen@hygon.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Borislav Petkov <bp@suse.de> Cc: tglx@linutronix.de Cc: mingo@redhat.com Cc: hpa@zytor.com Cc: x86@kernel.org Cc: thomas.lendacky@amd.com Link: https://lkml.kernel.org/r/9d93ed54a975f33ef7247e0967960f4ce5d3d990.1537533369.git.puwen@hygon.cn Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit 0b13bec7 upstream. The Hygon Dhyana CPU uses no delay in smp_quirk_init_udelay(), and does HLT on idle just like AMD does. Signed-off-by:
Pu Wen <puwen@hygon.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Borislav Petkov <bp@suse.de> Cc: bp@alien8.de Cc: tglx@linutronix.de Cc: mingo@redhat.com Cc: hpa@zytor.com Cc: x86@kernel.org Cc: thomas.lendacky@amd.com Link: https://lkml.kernel.org/r/87000fa82e273f5967c908448414228faf61e077.1537533369.git.puwen@hygon.cn Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit 39dc6f15 upstream. The Hygon Dhyana CPU has a special MSR way to force WB for memory >4GB, and support TOP_MEM2. Therefore, it is necessary to add Hygon Dhyana support in amd_special_default_mtrr(). The number of variable MTRRs for Hygon is 2 as AMD's. Signed-off-by:
Pu Wen <puwen@hygon.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Borislav Petkov <bp@suse.de> Cc: tglx@linutronix.de Cc: mingo@redhat.com Cc: hpa@zytor.com Cc: x86@kernel.org Cc: thomas.lendacky@amd.com Link: https://lkml.kernel.org/r/8246f81648d014601de3812ade40e85d9c50d9b3.1537533369.git.puwen@hygon.cn Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit d4f7423e upstream. The Hygon Dhyana CPU has a topology extensions bit in CPUID. With this bit, the kernel can get the cache information. So add support in cpuid4_cache_lookup_regs() to get the correct cache size. The Hygon Dhyana CPU also discovers num_cache_leaves via CPUID leaf 0x8000001d, so add support to it in find_num_cache_leaves(). Also add cacheinfo_hygon_init_llc_id() and init_hygon_cacheinfo() functions to initialize Dhyana cache info. Setup cache cpumap in the same way as AMD does. Signed-off-by:
Pu Wen <puwen@hygon.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Borislav Petkov <bp@suse.de> Cc: bp@alien8.de Cc: tglx@linutronix.de Cc: mingo@redhat.com Cc: hpa@zytor.com Cc: x86@kernel.org Cc: thomas.lendacky@amd.com Link: https://lkml.kernel.org/r/2a686b2ac0e2f5a1f2f5f101124d9dd44f949731.1537533369.git.puwen@hygon.cn Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pu Wen authored
commit c9661c1e upstream. Add x86 architecture support for a new processor: Hygon Dhyana Family 18h. Carve out initialization code needed by Dhyana into a separate compilation unit. To identify Hygon Dhyana CPU, add a new vendor type X86_VENDOR_HYGON. Since Dhyana uses AMD functionality to a large degree, select CPU_SUP_AMD which provides that functionality. [ bp: drop explicit license statement as it has an SPDX tag already. ] Signed-off-by:
Pu Wen <puwen@hygon.cn> Reviewed-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: tglx@linutronix.de Cc: mingo@redhat.com Cc: hpa@zytor.com Cc: x86@kernel.org Cc: thomas.lendacky@amd.com Link: https://lkml.kernel.org/r/1a882065223bacbde5726f3beaa70cebd8dcd814.1537533369.git.puwen@hygon.cn Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
陈佳骏 authored
euleros inclusion category: feature bugzilla: NA CVE: NA This patch export cpu time related items to vcpu_stat. Contain: steal, st_max, utime, stime, gtime The definitions of these items are: steal: cpu time VCPU waits for PCPU while it is servicing another VCPU st_max: max scheduling delay utime: cpu time in userspace stime: cpu time in sys gtime: cpu time in guest Through these items, user can get many cpu usage info of vcpu, such as: CPU Usage of Guest = gtime_delta / delta_cputime CPU Usage of Hyp = (utime_delta - gtime_delta + stime_delta) / delta_cputime CPU Usage of Steal = steal_delta / delta_cputime Max Scheduling Delay = st_max Signed-off-by:
liangpeng <liangpeng10@huawei.com> Signed-off-by:
chenjiajun <chenjiajun8@huawei.com> Reviewed-by:
zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
陈佳骏 authored
euleros inclusion category: feature bugzilla: NA CVE: NA This patch export remaining aarch64 exit items to vcpu_stat via debugfs. The items include: fp_asimd_exit_stat, irq_exit_stat, sys64_exit_stat, mabt_exit_stat, fail_entry_exit_stat, internal_error_exit_stat, unknown_ec_exit_stat, cp15_32_exit_stat, cp15_64_exit_stat, cp14_mr_exit_stat, cp14_ls_exit_stat, cp14_64_exit_stat, smc_exit_stat, sve_exit_stat, debug_exit_stat Signed-off-by:
Biaoxiang Ye <yebiaoxiang@huawei.com> Signed-off-by:
Zengruan Ye <yezengruan@huawei.com> Signed-off-by:
chenjiajun <chenjiajun8@huawei.com> Reviewed-by:
zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
陈佳骏 authored
euleros inclusion category: feature bugzilla: NA CVE: NA This patch create debugfs entry for vcpu stat. The entry path is /sys/kernel/debug/kvm/vcpu_stat. And vcpu_stat contains partial kvm exits items of vcpu, include: pid, hvc_exit_stat, wfe_exit_stat, wfi_exit_stat, mmio_exit_user, mmio_exit_kernel, exits Currently, The maximum vcpu limit is 1024. From this vcpu_stat, user can get the number of these kvm exits items over a period of time, which is helpful to monitor the virtual machine. Signed-off-by:
Zenghui Yu <yuzenghui@huawei.com> Signed-off-by:
chenjiajun <chenjiajun8@huawei.com> Reviewed-by:
zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Peng Liang authored
hulk inclusion category: bugfix bugzilla: NA CVE: NA linux/kvm.h should be self-contained so uint64_t should be replaced with __u64. Signed-off-by:
Peng Liang <liangpeng10@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Peng Liang authored
hulk inclusion category: feature bugzilla: NA CVE: NA Add KVM_CAP_ARM_CPU_FEATURE extension for userpace to check whether KVM supports to set CPU features in AArch64. Signed-off-by:
zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by:
Peng Liang <liangpeng10@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Peng Liang authored
hulk inclusion category: feature bugzilla: NA CVE: NA It's time to make ID registers configurable. When userspace (but not guest) want to set the values of ID registers, save the value in kvm_arch_vcpu so that guest can read the modified values. Signed-off-by:
zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by:
Peng Liang <liangpeng10@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Peng Liang authored
hulk inclusion category: feature bugzilla: NA CVE: NA To emulate the ID registers, we need a place to storage the values of the ID regsiters. Maybe putting in kvm_arch_vcpu is a good idea. This commit has no functional changes but only code refactor. When initializing a vcpu, get the values of the ID registers from arm64_ftr_regs and storage them in kvm_arch_vcpu. And we just read the value from kvm_arch_vcpu when getting/setting the value of the ID regs. Signed-off-by:
zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by:
Peng Liang <liangpeng10@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Peng Liang authored
hulk inclusion category: feature bugzilla: NA CVE: NA If we want to emulate ID registers, we need to initialize ID registers firstly. This commit is to add a helper function to traverse arm64_ftr_regs so that we can initialize ID registers from arm64_ftr_regs. Signed-off-by:
zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by:
Peng Liang <liangpeng10@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
- Oct 27, 2020
-
-
Juergen Gross authored
mainline inclusion from mainline-v5.10 commit e99502f7 category: bugfix bugzilla: NA CVE: CVE-2020-27673 -------------------------------- In case rogue guests are sending events at high frequency it might happen that xen_evtchn_do_upcall() won't stop processing events in dom0. As this is done in irq handling a crash might be the result. In order to avoid that, delay further inter-domain events after some time in xen_evtchn_do_upcall() by forcing eoi processing into a worker on the same cpu, thus inhibiting new events coming in. The time after which eoi processing is to be delayed is configurable via a new module parameter "event_loop_timeout" which specifies the maximum event loop time in jiffies (default: 2, the value was chosen after some tests showing that a value of 2 was the lowest with an only slight drop of dom0 network throughput while multiple guests performed an event storm). How long eoi processing will be delayed can be specified via another parameter "event_eoi_delay" (again in jiffies, default 10, again the value was chosen after testing with different delay values). This is part of XSA-332. Cc: stable@vger.kernel.org Reported-by:
Julien Grall <julien@xen.org> Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Stefano Stabellini <sstabellini@kernel.org> Reviewed-by:
Wei Liu <wl@xen.org> Conflicts: Documentation/admin-guide/kernel-parameters.txt drivers/xen/events/events_base.c drivers/xen/events/events_fifo.c drivers/xen/events/events_internal.h [yyl: adjust context] Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Juergen Gross authored
mainline inclusion from mainline-v5.10 commit 7beb290c category: bugfix bugzilla: NA CVE: CVE-2020-27673 Prepare for fixing CVE-2020-27673 -------------------------------- Today only fifo event channels have a cpu hotplug callback. In order to prepare for more percpu (de)init work move that callback into events_base.c and add percpu_init() and percpu_deinit() hooks to struct evtchn_ops. This is part of XSA-332. Cc: stable@vger.kernel.org Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Jan Beulich <jbeulich@suse.com> Reviewed-by:
Wei Liu <wl@xen.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Juergen Gross authored
mainline inclusion from mainline-v5.10 commit c44b849c category: bugfix bugzilla: NA CVE: NA -------------------------------- Instead of disabling the irq when an event is received and enabling it again when handled by the user process use the lateeoi model. This is part of XSA-332. Cc: stable@vger.kernel.org Reported-by:
Julien Grall <julien@xen.org> Signed-off-by:
Juergen Gross <jgross@suse.com> Tested-by:
Stefano Stabellini <sstabellini@kernel.org> Reviewed-by:
Stefano Stabellini <sstabellini@kernel.org> Reviewed-by:
Jan Beulich <jbeulich@suse.com> Reviewed-by:
Wei Liu <wl@xen.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Juergen Gross authored
mainline inclusion from mainline-v5.10 commit 54c9de89 category: bugfix bugzilla: NA CVE: CVE-2020-27673 Prepare for fixing CVE-2020-27673 -------------------------------- In order to avoid tight event channel related IRQ loops add a new framework of "late EOI" handling: the IRQ the event channel is bound to will be masked until the event has been handled and the related driver is capable to handle another event. The driver is responsible for unmasking the event channel via the new function xen_irq_lateeoi(). This is similar to binding an event channel to a threaded IRQ, but without having to structure the driver accordingly. In order to support a future special handling in case a rogue guest is sending lots of unsolicited events, add a flag to xen_irq_lateeoi() which can be set by the caller to indicate the event was a spurious one. This is part of XSA-332. Cc: stable@vger.kernel.org Reported-by:
Julien Grall <julien@xen.org> Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Jan Beulich <jbeulich@suse.com> Reviewed-by:
Stefano Stabellini <sstabellini@kernel.org> Reviewed-by:
Wei Liu <wl@xen.org> Conflicts: drivers/xen/events/events_base.c include/xen/events.h [yyl: replace evtchn_port_t with usigned int] Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Juergen Gross authored
mainline inclusion from mainline-v5.10 commit 073d0552 category: bugfix bugzilla: NA CVE: CVE-2020-27675 -------------------------------- Today it can happen that an event channel is being removed from the system while the event handling loop is active. This can lead to a race resulting in crashes or WARN() splats when trying to access the irq_info structure related to the event channel. Fix this problem by using a rwlock taken as reader in the event handling loop and as writer when deallocating the irq_info structure. As the observed problem was a NULL dereference in evtchn_from_irq() make this function more robust against races by testing the irq_info pointer to be not NULL before dereferencing it. And finally make all accesses to evtchn_to_irq[row][col] atomic ones in order to avoid seeing partial updates of an array element in irq handling. Note that irq handling can be entered only for event channels which have been valid before, so any not populated row isn't a problem in this regard, as rows are only ever added and never removed. This is XSA-331. Cc: stable@vger.kernel.org Reported-by:
Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reported-by:
Jinoh Kang <luke1337@theori.io> Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Stefano Stabellini <sstabellini@kernel.org> Reviewed-by:
Wei Liu <wl@xen.org> Conflicts: drivers/xen/events/events_base.c [yyl: adjust context] Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
- Oct 26, 2020
-
-
Chiqijun authored
driver inclusion category: bugfix bugzilla: 4472 ----------------------------------------------------------------------- update hinic version to 2.3.2.16 Signed-off-by:
Chiqijun <chiqijun@huawei.com> Reviewed-by:
Wangxiaoyun <cloud.wangxiaoyun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Chiqijun authored
driver inclusion category: bugfix bugzilla: 4472 ----------------------------------------------------------------------- When only hot activation of ucode, mgmt channel can still be used normally, otherwise it is not allowed to send commands to mgmt until the hot activation is completed. Signed-off-by:
Chiqijun <chiqijun@huawei.com> Reviewed-by:
Wangxiaoyun <cloud.wangxiaoyun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Chiqijun authored
driver inclusion category: bugfix bugzilla: 4472 ----------------------------------------------------------------------- During the loopback test, it cannot be guaranteed that the protocol stack will completely stop sending packets, which causes the loopback test packets and protocol stack packets to be sent at the same time, causing the loopback test to fail. This patch corrects it. Signed-off-by:
Chiqijun <chiqijun@huawei.com> Reviewed-by:
Wangxiaoyun <cloud.wangxiaoyun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Chiqijun authored
driver inclusion category: bugfix bugzilla: 4472 ----------------------------------------------------------------------- Hardware rx csum offload is a chip-level configuration, and VF is not allowed to turn it off. The force packet drop configuration is at the port level, VF can only configure the corresponding port. Signed-off-by:
Chiqijun <chiqijun@huawei.com> Reviewed-by:
Wangxiaoyun <cloud.wangxiaoyun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Chiqijun authored
driver inclusion category: bugfix bugzilla: 4472 ----------------------------------------------------------------------- The driver initializes the MAC address of all VFs to 00:00:00:00:00:00, but when we attempts to restore the MAC address back to 00:00:00:00:00:00 after it was modified using "ip link", driver responds with "Invalid argument". Some users need to roll back the MAC configuration without destroying the VF, so the driver should allows users to use "ip link" with 00:00:00:00:00:00 to revert the MAC to the origin state. Signed-off-by:
Chiqijun <chiqijun@huawei.com> Reviewed-by:
Wangxiaoyun <cloud.wangxiaoyun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Chiqijun authored
driver inclusion category: bugfix bugzilla: 4472 ----------------------------------------------------------------------- When using the ip link command to configure the MAC for the VF in the PF, the status 4 will be returned when the MAC is set on the VF; when the PF driver receives the status 4 returned by the firmwre, the MAC setting failed and an error should be reported. Signed-off-by:
Chiqijun <chiqijun@huawei.com> Reviewed-by:
Wangxiaoyun <cloud.wangxiaoyun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
- Oct 19, 2020
-
-
Luiz Augusto von Dentz authored
mainline inclusion from mainline-v5.10 commit b560a208 category: bugfix bugzilla: NA CVE: NA -------------------------------- This checks if BT_HS is enabled relecting it on MGMT_SETTING_HS instead of always reporting it as supported. Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Conflicts: net/bluetooth/mgmt.c [yyl: adjust context] Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-