* [PATCH] drm/etnaviv: fix crash in GPU suspend when init failed due to buffer placement
From: Lucas Stach @ 2018-07-23 14:34 UTC (permalink / raw)
To: dri-devel; +Cc: patchwork-lst, etnaviv, kernel, Russell King
When the suballocator was unable to provide a suitable buffer for the MMUv1
linear window, we roll back the GPU initialization. As the GPU is runtime
resumed at that point we need to clear the kernel cmdbuf suballoc entry to
properly skip any attempt to manipulate the cmdbuf when the GPU gets shut
down in the runtime suspend later on.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 18c2224ba0b8..ab8dfe7f69d6 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -799,6 +799,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
free_buffer:
etnaviv_cmdbuf_free(&gpu->buffer);
+ gpu->buffer.suballoc = NULL;
destroy_iommu:
etnaviv_iommu_destroy(gpu->mmu);
gpu->mmu = NULL;
--
2.18.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: [PATCH 2/3] crypto: hisilicon SEC security accelerator driver
From: Jonathan Cameron @ 2018-07-23 14:33 UTC (permalink / raw)
To: Stephan Müller
Cc: linux-crypto, herbert, davem, robh+dt, mark.rutland, devicetree,
linuxarm, xuzaibo, fanghao11, liguozhu, wangxiongfeng2
In-Reply-To: <1743404.tCjS6oGqku@positron.chronox.de>
On Fri, 20 Jul 2018 20:17:22 +0200
Stephan Müller <smueller@chronox.de> wrote:
> Am Montag, 16. Juli 2018, 12:43:41 CEST schrieb Jonathan Cameron:
>
> Hi Jonathan,
>
> > +static int sec_alg_skcipher_setkey_aes_xts(struct crypto_skcipher *tfm,
> > + const u8 *key, unsigned int
> > keylen) +{
> > + enum sec_cipher_alg alg;
> > +
> > + switch (keylen) {
> > + case AES_KEYSIZE_128 * 2:
> > + alg = SEC_C_AES_XTS_128;
> > + break;
> > + case AES_KEYSIZE_256 * 2:
> > + alg = SEC_C_AES_XTS_256;
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > +
> > + return sec_alg_skcipher_setkey(tfm, key, keylen, alg);
> > +}
>
> Can you please call the function xts_check_key or xts_verify_key before
> setting the key?
>
Will do.
Thanks,
Jonathan
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] block/vvfat: Fix crash when reporting error about too many files in directory
From: Kevin Wolf @ 2018-07-23 14:33 UTC (permalink / raw)
To: Thomas Huth; +Cc: qemu-block, Max Reitz, qemu-devel
In-Reply-To: <1531927703-9799-1-git-send-email-thuth@redhat.com>
Am 18.07.2018 um 17:28 hat Thomas Huth geschrieben:
> When using the vvfat driver with a directory that contains too many files,
> QEMU currently crashes. We are trying to print the wrong path variable here.
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
> block/vvfat.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/block/vvfat.c b/block/vvfat.c
> index fc41841..6ae7458 100644
> --- a/block/vvfat.c
> +++ b/block/vvfat.c
> @@ -975,8 +975,7 @@ static int init_directories(BDRVVVFATState* s,
> if (mapping->mode & MODE_DIRECTORY) {
> mapping->begin = cluster;
> if(read_directory(s, i)) {
> - error_setg(errp, "Could not read directory %s",
> - mapping->path);
> + error_setg(errp, "Could not read directory \"%s\"", s->path);
Hm, I'm not sure if that's right. Before this patch we were printing
the name of the subdirectory that couldn't be loaded, now it's the
parent directory.
My test case where this difference is visible is a subdirectory with
chmod 000.
> return -1;
> }
> mapping = array_get(&(s->mapping), i);
Maybe the right solution would be moving the reloading of mapping to
between the read_directory() call and the error path?
Kevin
^ permalink raw reply
* Re: [PATCH v1] earlyprintk configuration for rk3399 boards
From: Julien Grall @ 2018-07-23 14:33 UTC (permalink / raw)
To: Ігор Матущак
Cc: ihor.matushchak, xen-devel, Stefano Stabellini, xen-devel
In-Reply-To: <CAFq70MEKa4GSaWprALmjaDyqOJeHUsAkSF-d869X4irhsjLOSQ@mail.gmail.com>
On 06/07/18 12:04, Ігор Матущак wrote:
> Hello Julien,
Hi Ihor,
Sorry for the late reply.
>
> I suppose there is no such documentation, at least I didn't find any.
> Bringing up XEN 4.10.0 on RK3399 is my pet-project.
> My current target board is Ibox3399
> <https://www.aliexpress.com/item/RK3399-Development-Board-Ibox3399-2GB-DDR3-16GB-EMMC-Six-Core-A72-A53-Mali-T860-GPU-Android6/32816273232.html>
>
> At the moment I got dom0 running on this board and some test guest
> domain (both 4.4 kernels).
> Actually no changes made to XEN (except earlyprintk) at the moment, Xen
> works from the box.
Glad to see Xen booting out of box on RK3399 :).
The alias is only for convience. It would be possible to do the same
with 8250,0xff1a0000,2.
So instead of that patch, I would suggest to write down a documentation
for booting Xen on the board and early debugging.
What do you think?
Cheers,
>
> /BR,/
> /Ihor Matushchak/
>
> 2018-07-06 13:36 GMT+03:00 Julien Grall <julien.grall@arm.com
> <mailto:julien.grall@arm.com>>:
>
> Hello,
>
> On 04/07/18 21:55, ihor.matushchak@foobox.net
> <mailto:ihor.matushchak@foobox.net> wrote:
>
> From: Ihor Matushchak <ihor.matushchak@foobox.net
> <mailto:ihor.matushchak@foobox.net>>
>
> This patch enables earlyprintk for Rockchip rk3399 based SoC.
>
> Is there any missing pieces in Xen to boot on Rockchip? I would also
> quite like to see some documentation how to boot Xen on that platform.
>
> Cheers,
>
>
>
> Ihor Matushchak (1):
> xen:arm:earlyprintk configuration for rk3399 boards
>
> docs/misc/arm/early-printk.txt | 1 +
> xen/arch/arm/Rules.mk | 1 +
> 2 files changed, 2 insertions(+)
>
>
> --
> Julien Grall
>
>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [PATCH] mwifiex: Fix skipped vendor specific IEs
From: roman.stratiienko @ 2018-07-23 13:31 UTC (permalink / raw)
To: akarwar
Cc: nishants, kvalo, linux-wireless, netdev, linux-kernel,
Roman Stratiienko
From: Roman Stratiienko <roman.stratiienko@globallogic.com>
Only microsoft specific IE is added by FW
Let other IEs to pass from userspace
Signed-off-by: Roman Stratiienko <roman.stratiienko@globallogic.com>
---
drivers/net/wireless/marvell/mwifiex/ie.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/ie.c b/drivers/net/wireless/marvell/mwifiex/ie.c
index c488c30..c58b345 100644
--- a/drivers/net/wireless/marvell/mwifiex/ie.c
+++ b/drivers/net/wireless/marvell/mwifiex/ie.c
@@ -353,8 +353,16 @@ static int mwifiex_uap_parse_tail_ies(struct mwifiex_private *priv,
case WLAN_EID_HT_OPERATION:
case WLAN_EID_VHT_CAPABILITY:
case WLAN_EID_VHT_OPERATION:
- case WLAN_EID_VENDOR_SPECIFIC:
break;
+ case WLAN_EID_VENDOR_SPECIFIC:
+ /* Skip only Microsoft IE that added by FW
+ * Let other vendor specific IE to pass
+ */
+ if (cfg80211_find_vendor_ie(WLAN_OUI_MICROSOFT,
+ WLAN_OUI_TYPE_MICROSOFT_WMM,
+ (const u8 *)hdr,
+ hdr->len + sizeof(struct ieee_types_header)))
+ break;
default:
memcpy(gen_ie->ie_buffer + ie_len, hdr,
hdr->len + sizeof(struct ieee_types_header));
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] x86/hvm: Disallow unknown MSR_EFER bits
From: Wei Liu @ 2018-07-23 14:33 UTC (permalink / raw)
To: Andrew Cooper
Cc: Sergey Dyasli, Roger Pau Monné, Wei Liu, Jan Beulich,
Xen-devel
In-Reply-To: <1532353790-28875-1-git-send-email-andrew.cooper3@citrix.com>
On Mon, Jul 23, 2018 at 02:49:50PM +0100, Andrew Cooper wrote:
> It turns out that nothing ever prevented HVM guests from trying to set unknown
> EFER bits. Generally, this results in a vmentry failure.
>
> For Intel hardware, all implemented bits are covered by the checks.
>
> For AMD hardware, the only EFER bit which isn't covered by the checks is TCE
> (which AFAICT is specific to AMD Fam15/16 hardware). We never advertise TCE
> in CPUID, but it isn't a security problem to have TCE unexpected enabled in
> guest context.
>
> Disallow the setting of bits outside of the EFER_KNOWN_MASK, which prevents
> any vmentry failures for guests, yielding #GP instead.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH] x86/spec-ctrl: Fix the parsing of xpti= on fixed Intel hardware
From: Wei Liu @ 2018-07-23 14:33 UTC (permalink / raw)
To: Andrew Cooper
Cc: Juergen Gross, Sergey Dyasli, Wei Liu, Xen-devel, Jan Beulich,
Roger Pau Monné
In-Reply-To: <1532353682-28335-1-git-send-email-andrew.cooper3@citrix.com>
On Mon, Jul 23, 2018 at 02:48:02PM +0100, Andrew Cooper wrote:
> The calls to xpti_init_default() in parse_xpti() are buggy. The CPUID data
> hasn't been fetched that early, and boot_cpu_has(X86_FEATURE_ARCH_CAPS) will
> always evaluate false.
>
> As a result, the default case won't disable XPTI on Intel hardware which
> advertises ARCH_CAPABILITIES_RDCL_NO.
>
> Simplify parse_xpti() to solely the setting of opt_xpti according to the
> passed string, and have init_speculation_mitigations() call
> xpti_init_default() if appropiate. Drop the force parameter, and pass caps
> instead, to avoid redundant re-reading of MSR_ARCH_CAPS.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [RFC PATCH] sched/deadline: sched_getattr() returns absolute dl-task information
From: Patrick Bellasi @ 2018-07-23 14:31 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Alessio Balsini, linux-kernel, Joel Fernandes, Juri Lelli,
Tommaso Cucinotta, Luca Abeni, Claudio Scordino,
Daniel Bristot de Oliveira, Ingo Molnar
In-Reply-To: <20180723141322.GZ2458@hirez.programming.kicks-ass.net>
On 23-Jul 16:13, Peter Zijlstra wrote:
> On Mon, Jul 23, 2018 at 01:49:46PM +0100, Patrick Bellasi wrote:
> > On 23-Jul 11:49, Peter Zijlstra wrote:
> >
> > [...]
> >
> > > > -void __getparam_dl(struct task_struct *p, struct sched_attr *attr)
> > > > +void __getparam_dl(struct task_struct *p, struct sched_attr *attr,
> > > > + unsigned int flags)
> > > > {
> > > > struct sched_dl_entity *dl_se = &p->dl;
> > > >
> > > > attr->sched_priority = p->rt_priority;
> > > > - attr->sched_runtime = dl_se->dl_runtime;
> > > > - attr->sched_deadline = dl_se->dl_deadline;
> > > > +
> > > > + if (flags & SCHED_GETATTR_FLAGS_DL_ABSOLUTE) {
> > > > + /*
> > > > + * If the task is not running, its runtime is already
> > > > + * properly accounted. Otherwise, update clocks and the
> > > > + * statistics for the task.
> > > > + */
> > > > + if (task_running(task_rq(p), p)) {
> > > > + struct rq_flags rf;
> > > > + struct rq *rq;
> > > > +
> > > > + rq = task_rq_lock(p, &rf);
> > > > + sched_clock_tick();
> > > > + update_rq_clock(rq);
> > > > + task_tick_dl(rq, p, 0);
> > >
> > > Do we really want task_tick_dl() here, or update_curr_dl()?
> >
> > I think this was to cover the case of a syscall being called while the
> > task is running and we are midway between two ticks...
>
> Sure, I know what it's there for, just saying that update_curr_dl()
> would've updated the accounting as well. Calling tick stuff from !tick
> context is a wee bit dodgy.
Right, I think it depends on how much we want to be "precise" in closing
a control loop with user-space.
On Android we have ticks every 3-4ms, I'm wondering if this maximum
"latency" on measuring the remaining run-time can introduce a too big
error for certain applications...
Alessio: you have an interesting low-latency audio use-case on hand,
do you think we can tolerate a 4ms error in remaining run-time
readings?
[...]
> > Which means we should use something like:
> >
> > if (flags & SCHED_GETATTR_FLAGS_DL_ABSOLUTE) {
> > /* Lock the task and the RQ before any other check and upate */
> > rq = task_rq_lock(p, &rf);
> >
> > /* Check the task is still DL ?*/
> >
> > /* Update task stats */
> >
> > task_rq_unlock(rq, p, &rf);
> > }
> >
> > right?
>
> Yeah, something along those lines.
>
> > If that's better, then we should probably even better move the
> > task_rq_lock at the beginning of SYSCALL_DEFINE4(sched_getattr()) ?
>
> Hurm.. yes, we should probably have the has_dl_policy test under the
> lock too. Which is really annoying, because this basically turns a
> lockless syscall into locked one.
Indeed...
> Another method would be to have __getparam_dl() 'fail' and retry if it
> finds !has_dl_policy() once we have the lock. That would retain the
> lockless nature for all current use-cases and only incur the locking
> overhead for this new case.
... right, this is actually the best solution to have a bit more
guarantees for the new DL control scenarios without affecting existing
ones!
--
#include <best/regards.h>
Patrick Bellasi
^ permalink raw reply
* [Bug 106707] [CI] igt@gem_exec_schedule@deep-* - fail - Failed assertion: __vgem_fence_signal(fd, fence) == 0
From: bugzilla-daemon @ 2018-07-23 14:30 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-106707-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 970 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=106707
--- Comment #10 from Martin Peres <martin.peres@free.fr> ---
New bug created: https://bugs.freedesktop.org/show_bug.cgi?id=107341
However, I would also like to documented that we can also see this bug in GLK:
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_74/fi-glk-dsi/igt@gem_exec_schedule@deep-render.html
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_76/fi-glk-dsi/igt@gem_exec_schedule@deep-vebox.html
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_76/fi-glk-dsi/igt@gem_exec_schedule@deep-bsd.html
(gem_exec_schedule:1158) igt_vgem-CRITICAL: Test assertion failure function
vgem_fence_signal, file ../lib/igt_vgem.c:193:
(gem_exec_schedule:1158) igt_vgem-CRITICAL: Failed assertion:
__vgem_fence_signal(fd, fence) == 0
(gem_exec_schedule:1158) igt_vgem-CRITICAL: error: -110 != 0
Subtest deep-bsd failed.
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 2515 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH] gpu: drm: amdgpu: Replace mdelay with msleep in cik_pcie_gen3_enable()
From: Jia-Ju Bai @ 2018-07-23 14:29 UTC (permalink / raw)
To: alexander.deucher, christian.koenig, David1.Zhou, airlied,
Rex.Zhu, harry.wentland, Samuel.Li
Cc: amd-gfx, dri-devel, linux-kernel, Jia-Ju Bai
cik_pcie_gen3_enable() is only called by cik_common_hw_init(), which is
never called in atomic context.
cik_pcie_gen3_enable() calls mdelay() to busily wait, which is not
necessary.
mdelay() can be replaced with msleep().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/gpu/drm/amd/amdgpu/cik.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c b/drivers/gpu/drm/amd/amdgpu/cik.c
index 0df22030e713..5b7fab2c2008 100644
--- a/drivers/gpu/drm/amd/amdgpu/cik.c
+++ b/drivers/gpu/drm/amd/amdgpu/cik.c
@@ -1476,7 +1476,7 @@ static void cik_pcie_gen3_enable(struct amdgpu_device *adev)
tmp |= PCIE_LC_CNTL4__LC_REDO_EQ_MASK;
WREG32_PCIE(ixPCIE_LC_CNTL4, tmp);
- mdelay(100);
+ msleep(100);
/* linkctl */
pci_read_config_word(root, bridge_pos + PCI_EXP_LNKCTL, &tmp16);
--
2.17.0
^ permalink raw reply related
* [PATCH v2 13/17] x86/xen: enable Hygon support to Xen
From: Pu Wen @ 2018-07-23 13:20 UTC (permalink / raw)
To: tglx, bp, thomas.lendacky, mingo, hpa, peterz, tony.luck,
pbonzini, rkrcmar, boris.ostrovsky, jgross, rjw, lenb,
viresh.kumar, mchehab, trenn, shuah, JBeulich, x86
Cc: linux-kernel, linux-arch, kvm, xen-devel
In-Reply-To: <1532352037-7151-1-git-send-email-puwen@hygon.cn>
To make Xen work correctly on Hygon platforms, reuse AMD's Xen support
code path and add vendor check for Hygon along with AMD.
Signed-off-by: Pu Wen <puwen@hygon.cn>
---
arch/x86/xen/pmu.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c
index 7d00d4a..e2bee70 100644
--- a/arch/x86/xen/pmu.c
+++ b/arch/x86/xen/pmu.c
@@ -68,7 +68,8 @@ static __read_mostly int intel_num_arch_counters, intel_num_fixed_counters;
static void xen_pmu_arch_init(void)
{
- if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
switch (boot_cpu_data.x86) {
case 0x15:
@@ -285,7 +286,8 @@ static bool xen_amd_pmu_emulate(unsigned int msr, u64 *val, bool is_read)
bool pmu_msr_read(unsigned int msr, uint64_t *val, int *err)
{
- if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
if (is_amd_pmu_msr(msr)) {
if (!xen_amd_pmu_emulate(msr, val, 1))
*val = native_read_msr_safe(msr, err);
@@ -308,7 +310,8 @@ bool pmu_msr_write(unsigned int msr, uint32_t low, uint32_t high, int *err)
{
uint64_t val = ((uint64_t)high << 32) | low;
- if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
if (is_amd_pmu_msr(msr)) {
if (!xen_amd_pmu_emulate(msr, &val, 0))
*err = native_write_msr_safe(msr, low, high);
@@ -379,7 +382,8 @@ static unsigned long long xen_intel_read_pmc(int counter)
unsigned long long xen_read_pmc(int counter)
{
- if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
return xen_amd_read_pmc(counter);
else
return xen_intel_read_pmc(counter);
--
2.7.4
^ permalink raw reply related
* [PATCH v2 10/17] x86/events: enable Hygon support to PMU infrastructure
From: Pu Wen @ 2018-07-23 13:20 UTC (permalink / raw)
To: tglx, bp, thomas.lendacky, mingo, hpa, peterz, tony.luck,
pbonzini, rkrcmar, boris.ostrovsky, jgross, rjw, lenb,
viresh.kumar, mchehab, trenn, shuah, JBeulich, x86
Cc: linux-kernel, linux-arch, kvm, xen-devel
In-Reply-To: <1532352037-7151-1-git-send-email-puwen@hygon.cn>
Hygon PMU arch is similar to AMD Family 17h. To support Hygon PMU, the
initialization flow for it just call amd_pmu_init() and change PMU name
to "HYGON". To share AMD's flow, add code check for Hygon family ID 18h
to run the code path of AMD family 17h in core/uncore functions.
Signed-off-by: Pu Wen <puwen@hygon.cn>
---
arch/x86/events/amd/core.c | 4 ++++
arch/x86/events/amd/uncore.c | 12 +++++++-----
arch/x86/events/core.c | 4 ++++
3 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
index c84584b..d2b29bf 100644
--- a/arch/x86/events/amd/core.c
+++ b/arch/x86/events/amd/core.c
@@ -669,6 +669,10 @@ static int __init amd_core_pmu_init(void)
* We fallback to using default amd_get_event_constraints.
*/
break;
+ case 0x18:
+ pr_cont("Fam18h ");
+ /* Fallback to using default amd_get_event_constraints. */
+ break;
default:
pr_err("core perfctr but no constraints; unknown hardware!\n");
return -ENODEV;
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index 981ba5e..92ea280 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -507,17 +507,19 @@ static int __init amd_uncore_init(void)
{
int ret = -ENODEV;
- if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
+ if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
+ boot_cpu_data.x86_vendor != X86_VENDOR_HYGON)
return -ENODEV;
if (!boot_cpu_has(X86_FEATURE_TOPOEXT))
return -ENODEV;
- if (boot_cpu_data.x86 == 0x17) {
+ if (boot_cpu_data.x86 == 0x17 || boot_cpu_data.x86 == 0x18) {
/*
- * For F17h, the Northbridge counters are repurposed as Data
- * Fabric counters. Also, L3 counters are supported too. The PMUs
- * are exported based on family as either L2 or L3 and NB or DF.
+ * For F17h or F18h, the Northbridge counters are
+ * repurposed as DataFabric counters. Also, L3 counters
+ * are supported too. The PMUs are exported based on
+ * family as either L2 or L3 and NB or DF.
*/
num_counters_nb = NUM_COUNTERS_NB;
num_counters_llc = NUM_COUNTERS_L3;
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 5f4829f..93e026b 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -1776,6 +1776,10 @@ static int __init init_hw_perf_events(void)
case X86_VENDOR_AMD:
err = amd_pmu_init();
break;
+ case X86_VENDOR_HYGON:
+ err = amd_pmu_init();
+ x86_pmu.name = "HYGON";
+ break;
default:
err = -ENOTSUPP;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2 01/17] x86/cpu: create Dhyana init file and register new cpu_dev to system
From: Pu Wen @ 2018-07-23 13:20 UTC (permalink / raw)
To: tglx, bp, thomas.lendacky, mingo, hpa, peterz, tony.luck,
pbonzini, rkrcmar, boris.ostrovsky, jgross, rjw, lenb,
viresh.kumar, mchehab, trenn, shuah, JBeulich, x86
Cc: linux-kernel, linux-arch, kvm, xen-devel
In-Reply-To: <1532352037-7151-1-git-send-email-puwen@hygon.cn>
Add x86 architecture support for new processor Hygon Dhyana Family 18h.
Rework to create a separated file(arch/x86/kernel/cpu/hygon.c) from the
AMD init one(arch/x86/kernel/cpu/amd.c) to initialize Dhyana CPU. In
this way we can remove old AMD architecture support codes from Hygon
code path and generate a clear initialization flow for Hygon processors,
it also reduce long-term maintenance effort.
Also add hygon.c Maintainer information in accordance.
To identify Hygon processors, add a new vendor type X86_VENDOR_HYGON(9)
for system recognition.
To enable Hygon processor config, add a separated Kconfig entry(CPU_SUP_
HYGON) for Dhyana CPU in kernel config setup.
Signed-off-by: Pu Wen <puwen@hygon.cn>
---
MAINTAINERS | 6 +
arch/x86/Kconfig.cpu | 13 ++
arch/x86/include/asm/processor.h | 3 +-
arch/x86/kernel/cpu/Makefile | 1 +
arch/x86/kernel/cpu/hygon.c | 401 +++++++++++++++++++++++++++++++++++++++
5 files changed, 423 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/kernel/cpu/hygon.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 0fe4228..ade39f2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6604,6 +6604,12 @@ S: Maintained
F: mm/memory-failure.c
F: mm/hwpoison-inject.c
+HYGON PROCESSOR SUPPORT
+M: Pu Wen <puwen@hygon.cn>
+L: linux-arch@vger.kernel.org
+S: Supported
+F: arch/x86/kernel/cpu/hygon.c
+
Hyper-V CORE AND DRIVERS
M: "K. Y. Srinivasan" <kys@microsoft.com>
M: Haiyang Zhang <haiyangz@microsoft.com>
diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 638411f..2e92267 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -426,6 +426,19 @@ config CPU_SUP_AMD
If unsure, say N.
+config CPU_SUP_HYGON
+ default y
+ bool "Support Hygon processors" if PROCESSOR_SELECT
+ help
+ This enables detection, tunings and quirks for Hygon processors
+
+ You need this enabled if you want your kernel to run on an
+ Hygon CPU. Disabling this option on other types of CPUs
+ makes the kernel a tiny bit smaller. Disabling it on an Hygon
+ CPU might render the kernel unbootable.
+
+ If unsure, say N.
+
config CPU_SUP_CENTAUR
default y
bool "Support Centaur processors" if PROCESSOR_SELECT
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index cfd29ee..b4f4fbd 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -153,7 +153,8 @@ enum cpuid_regs_idx {
#define X86_VENDOR_CENTAUR 5
#define X86_VENDOR_TRANSMETA 7
#define X86_VENDOR_NSC 8
-#define X86_VENDOR_NUM 9
+#define X86_VENDOR_HYGON 9
+#define X86_VENDOR_NUM 10
#define X86_VENDOR_UNKNOWN 0xff
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 7a40196..889ce58 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_X86_FEATURE_NAMES) += capflags.o powerflags.o
obj-$(CONFIG_CPU_SUP_INTEL) += intel.o intel_pconfig.o
obj-$(CONFIG_CPU_SUP_AMD) += amd.o
+obj-$(CONFIG_CPU_SUP_HYGON) += hygon.o
obj-$(CONFIG_CPU_SUP_CYRIX_32) += cyrix.o
obj-$(CONFIG_CPU_SUP_CENTAUR) += centaur.o
obj-$(CONFIG_CPU_SUP_TRANSMETA_32) += transmeta.o
diff --git a/arch/x86/kernel/cpu/hygon.c b/arch/x86/kernel/cpu/hygon.c
new file mode 100644
index 0000000..cc296e5
--- /dev/null
+++ b/arch/x86/kernel/cpu/hygon.c
@@ -0,0 +1,401 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Hygon Processor Support for Linux
+ *
+ * Copyright (c) Chengdu Haiguang IC Design Co., Ltd.
+ *
+ * Author: 2018 Pu Wen <puwen@hygon.cn>
+ *
+ * This file is licensed under the terms of the GNU General
+ * License v2.0 or later. See file COPYING for details.
+ */
+#include <linux/io.h>
+
+#include <asm/cpu.h>
+#include <asm/smp.h>
+#include <asm/cacheinfo.h>
+#include <asm/spec-ctrl.h>
+#include <asm/delay.h>
+#ifdef CONFIG_X86_64
+# include <asm/set_memory.h>
+#endif
+
+#include "cpu.h"
+
+/*
+ * nodes_per_socket: Stores the number of nodes per socket.
+ * Refer to CPUID Fn8000_001E_ECX Node Identifiers[10:8]
+ */
+static u32 nodes_per_socket = 1;
+
+#ifdef CONFIG_NUMA
+/*
+ * To workaround broken NUMA config. Read the comment in
+ * srat_detect_node().
+ */
+static int nearby_node(int apicid)
+{
+ int i, node;
+
+ for (i = apicid - 1; i >= 0; i--) {
+ node = __apicid_to_node[i];
+ if (node != NUMA_NO_NODE && node_online(node))
+ return node;
+ }
+ for (i = apicid + 1; i < MAX_LOCAL_APIC; i++) {
+ node = __apicid_to_node[i];
+ if (node != NUMA_NO_NODE && node_online(node))
+ return node;
+ }
+ return first_node(node_online_map); /* Shouldn't happen */
+}
+#endif
+
+/*
+ * Fixup core topology information for
+ * (1) Hygon multi-node processors
+ * Assumption: Number of cores in each internal node is the same.
+ * (2) Hygon processors supporting compute units
+ */
+static void hygon_get_topology(struct cpuinfo_x86 *c)
+{
+ u8 node_id;
+ int cpu = smp_processor_id();
+
+ /* get information required for multi-node processors */
+ if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
+ int err;
+ u32 eax, ebx, ecx, edx;
+
+ cpuid(0x8000001e, &eax, &ebx, &ecx, &edx);
+
+ node_id = ecx & 0xff;
+ smp_num_siblings = ((ebx >> 8) & 0xff) + 1;
+
+ c->cpu_core_id = ebx & 0xff;
+
+ if (smp_num_siblings > 1)
+ c->x86_max_cores /= smp_num_siblings;
+
+ /*
+ * In case leaf B is available, use it to derive
+ * topology information.
+ */
+ err = detect_extended_topology(c);
+ if (!err)
+ c->x86_coreid_bits = get_count_order(c->x86_max_cores);
+
+ } else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
+ u64 value;
+
+ rdmsrl(MSR_FAM10H_NODE_ID, value);
+ node_id = value & 7;
+
+ per_cpu(cpu_llc_id, cpu) = node_id;
+ } else
+ return;
+
+ if (nodes_per_socket > 1)
+ set_cpu_cap(c, X86_FEATURE_AMD_DCM);
+}
+
+/*
+ * On Hygon setup the lower bits of the APIC id distinguish the cores.
+ * Assumes number of cores is a power of two.
+ */
+static void hygon_detect_cmp(struct cpuinfo_x86 *c)
+{
+ unsigned int bits;
+ int cpu = smp_processor_id();
+
+ bits = c->x86_coreid_bits;
+ /* Low order bits define the core id (index of core in socket) */
+ c->cpu_core_id = c->initial_apicid & ((1 << bits)-1);
+ /* Convert the initial APIC ID into the socket ID */
+ c->phys_proc_id = c->initial_apicid >> bits;
+ /* use socket ID also for last level cache */
+ per_cpu(cpu_llc_id, cpu) = c->phys_proc_id;
+}
+
+static void srat_detect_node(struct cpuinfo_x86 *c)
+{
+#ifdef CONFIG_NUMA
+ int cpu = smp_processor_id();
+ int node;
+ unsigned int apicid = c->apicid;
+
+ node = numa_cpu_node(cpu);
+ if (node == NUMA_NO_NODE)
+ node = per_cpu(cpu_llc_id, cpu);
+
+ /*
+ * On multi-fabric platform (e.g. Numascale NumaChip) a
+ * platform-specific handler needs to be called to fixup some
+ * IDs of the CPU.
+ */
+ if (x86_cpuinit.fixup_cpu_id)
+ x86_cpuinit.fixup_cpu_id(c, node);
+
+ if (!node_online(node)) {
+ /*
+ * Two possibilities here:
+ *
+ * - The CPU is missing memory and no node was created. In
+ * that case try picking one from a nearby CPU.
+ *
+ * - The APIC IDs differ from the HyperTransport node IDs.
+ * Assume they are all increased by a constant offset, but
+ * in the same order as the HT nodeids. If that doesn't
+ * result in a usable node fall back to the path for the
+ * previous case.
+ *
+ * This workaround operates directly on the mapping between
+ * APIC ID and NUMA node, assuming certain relationship
+ * between APIC ID, HT node ID and NUMA topology. As going
+ * through CPU mapping may alter the outcome, directly
+ * access __apicid_to_node[].
+ */
+ int ht_nodeid = c->initial_apicid;
+
+ if (__apicid_to_node[ht_nodeid] != NUMA_NO_NODE)
+ node = __apicid_to_node[ht_nodeid];
+ /* Pick a nearby node */
+ if (!node_online(node))
+ node = nearby_node(apicid);
+ }
+ numa_set_node(cpu, node);
+#endif
+}
+
+static void early_init_hygon_mc(struct cpuinfo_x86 *c)
+{
+#ifdef CONFIG_SMP
+ unsigned int bits, ecx;
+
+ /* Multi core CPU? */
+ if (c->extended_cpuid_level < 0x80000008)
+ return;
+
+ ecx = cpuid_ecx(0x80000008);
+
+ c->x86_max_cores = (ecx & 0xff) + 1;
+
+ /* CPU telling us the core id bits shift? */
+ bits = (ecx >> 12) & 0xF;
+
+ /* Otherwise recompute */
+ if (bits == 0) {
+ while ((1 << bits) < c->x86_max_cores)
+ bits++;
+ }
+
+ c->x86_coreid_bits = bits;
+#endif
+}
+
+static void bsp_init_hygon(struct cpuinfo_x86 *c)
+{
+#ifdef CONFIG_X86_64
+ unsigned long long tseg;
+
+ /*
+ * Split up direct mapping around the TSEG SMM area.
+ * Don't do it for gbpages because there seems very little
+ * benefit in doing so.
+ */
+ if (!rdmsrl_safe(MSR_K8_TSEG_ADDR, &tseg)) {
+ unsigned long pfn = tseg >> PAGE_SHIFT;
+
+ pr_debug("tseg: %010llx\n", tseg);
+ if (pfn_range_is_mapped(pfn, pfn + 1))
+ set_memory_4k((unsigned long)__va(tseg), 1);
+ }
+#endif
+
+ if (cpu_has(c, X86_FEATURE_CONSTANT_TSC)) {
+ u64 val;
+
+ rdmsrl(MSR_K7_HWCR, val);
+ if (!(val & BIT(24)))
+ pr_warn(FW_BUG "TSC doesn't count with P0 frequency!\n");
+ }
+
+ if (cpu_has(c, X86_FEATURE_MWAITX))
+ use_mwaitx_delay();
+
+ if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
+ u32 ecx;
+
+ ecx = cpuid_ecx(0x8000001e);
+ nodes_per_socket = ((ecx >> 8) & 7) + 1;
+ } else if (boot_cpu_has(X86_FEATURE_NODEID_MSR)) {
+ u64 value;
+
+ rdmsrl(MSR_FAM10H_NODE_ID, value);
+ nodes_per_socket = ((value >> 3) & 7) + 1;
+ }
+
+ if (!boot_cpu_has(X86_FEATURE_AMD_SSBD) &&
+ !boot_cpu_has(X86_FEATURE_VIRT_SSBD)) {
+ /*
+ * Try to cache the base value so further operations can
+ * avoid RMW. If that faults, do not enable SSBD.
+ */
+ if (!rdmsrl_safe(MSR_AMD64_LS_CFG, &x86_amd_ls_cfg_base)) {
+ setup_force_cpu_cap(X86_FEATURE_LS_CFG_SSBD);
+ setup_force_cpu_cap(X86_FEATURE_SSBD);
+ x86_amd_ls_cfg_ssbd_mask = 1ULL << 10;
+ }
+ }
+}
+
+static void early_init_hygon(struct cpuinfo_x86 *c)
+{
+ u32 dummy;
+
+ early_init_hygon_mc(c);
+
+ rdmsr_safe(MSR_AMD64_PATCH_LEVEL, &c->microcode, &dummy);
+
+ /*
+ * c->x86_power is 8000_0007 edx. Bit 8 is TSC runs at constant rate
+ * with P/T states and does not stop in deep C-states
+ */
+ if (c->x86_power & (1 << 8)) {
+ set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
+ set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC);
+ }
+
+ /* Bit 12 of 8000_0007 edx is accumulated power mechanism. */
+ if (c->x86_power & BIT(12))
+ set_cpu_cap(c, X86_FEATURE_ACC_POWER);
+
+ set_cpu_cap(c, X86_FEATURE_SYSCALL32);
+
+#if defined(CONFIG_X86_LOCAL_APIC) && defined(CONFIG_PCI)
+ /*
+ * ApicID can always be treated as an 8-bit value for Hygon APIC So, we
+ * can safely set X86_FEATURE_EXTD_APICID unconditionally.
+ */
+ if (boot_cpu_has(X86_FEATURE_APIC))
+ set_cpu_cap(c, X86_FEATURE_EXTD_APICID);
+#endif
+
+ /*
+ * This is only needed to tell the kernel whether to use VMCALL
+ * and VMMCALL. VMMCALL is never executed except under virt, so
+ * we can set it unconditionally.
+ */
+ set_cpu_cap(c, X86_FEATURE_VMMCALL);
+}
+
+static void init_hygon(struct cpuinfo_x86 *c)
+{
+ early_init_hygon(c);
+
+ /*
+ * Bit 31 in normal CPUID used for nonstandard 3DNow ID;
+ * 3DNow is IDd by bit 31 in extended CPUID (1*32+31) anyway
+ */
+ clear_cpu_cap(c, 0*32+31);
+
+ set_cpu_cap(c, X86_FEATURE_REP_GOOD);
+
+ /* get apicid instead of initial apic id from cpuid */
+ c->apicid = hard_smp_processor_id();
+
+ set_cpu_cap(c, X86_FEATURE_ZEN);
+
+ cpu_detect_cache_sizes(c);
+
+ /* Multi core CPU? */
+ if (c->extended_cpuid_level >= 0x80000008) {
+ hygon_detect_cmp(c);
+ hygon_get_topology(c);
+ srat_detect_node(c);
+ }
+
+ set_cpu_cap(c, X86_FEATURE_K8);
+
+ if (cpu_has(c, X86_FEATURE_XMM2)) {
+ unsigned long long val;
+ int ret;
+
+ /*
+ * A serializing LFENCE has less overhead than MFENCE, so
+ * use it for execution serialization. On families which
+ * don't have that MSR, LFENCE is already serializing.
+ * msr_set_bit() uses the safe accessors, too, even if the MSR
+ * is not present.
+ */
+ msr_set_bit(MSR_F10H_DECFG,
+ MSR_F10H_DECFG_LFENCE_SERIALIZE_BIT);
+
+ /*
+ * Verify that the MSR write was successful (could be running
+ * under a hypervisor) and only then assume that LFENCE is
+ * serializing.
+ */
+ ret = rdmsrl_safe(MSR_F10H_DECFG, &val);
+ if (!ret && (val & MSR_F10H_DECFG_LFENCE_SERIALIZE)) {
+ /* A serializing LFENCE stops RDTSC speculation */
+ set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
+ } else {
+ /* MFENCE stops RDTSC speculation */
+ set_cpu_cap(c, X86_FEATURE_MFENCE_RDTSC);
+ }
+ }
+
+ /*
+ * Hygon processors have APIC timer running in deep C states.
+ */
+ set_cpu_cap(c, X86_FEATURE_ARAT);
+
+ /* Hygon CPUs don't reset SS attributes on SYSRET, Xen does. */
+ if (!cpu_has(c, X86_FEATURE_XENPV))
+ set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
+}
+
+static void cpu_detect_tlb_hygon(struct cpuinfo_x86 *c)
+{
+ u32 ebx, eax, ecx, edx;
+ u16 mask = 0xfff;
+
+ if (c->extended_cpuid_level < 0x80000006)
+ return;
+
+ cpuid(0x80000006, &eax, &ebx, &ecx, &edx);
+
+ tlb_lld_4k[ENTRIES] = (ebx >> 16) & mask;
+ tlb_lli_4k[ENTRIES] = ebx & mask;
+
+ /* Handle DTLB 2M and 4M sizes, fall back to L1 if L2 is disabled */
+ if (!((eax >> 16) & mask))
+ tlb_lld_2m[ENTRIES] = (cpuid_eax(0x80000005) >> 16) & 0xff;
+ else
+ tlb_lld_2m[ENTRIES] = (eax >> 16) & mask;
+
+ /* a 4M entry uses two 2M entries */
+ tlb_lld_4m[ENTRIES] = tlb_lld_2m[ENTRIES] >> 1;
+
+ /* Handle ITLB 2M and 4M sizes, fall back to L1 if L2 is disabled */
+ if (!(eax & mask)) {
+ cpuid(0x80000005, &eax, &ebx, &ecx, &edx);
+ tlb_lli_2m[ENTRIES] = eax & 0xff;
+ } else
+ tlb_lli_2m[ENTRIES] = eax & mask;
+
+ tlb_lli_4m[ENTRIES] = tlb_lli_2m[ENTRIES] >> 1;
+}
+
+static const struct cpu_dev hygon_cpu_dev = {
+ .c_vendor = "Hygon",
+ .c_ident = { "HygonGenuine" },
+ .c_early_init = early_init_hygon,
+ .c_detect_tlb = cpu_detect_tlb_hygon,
+ .c_bsp_init = bsp_init_hygon,
+ .c_init = init_hygon,
+ .c_x86_vendor = X86_VENDOR_HYGON,
+};
+
+cpu_dev_register(hygon_cpu_dev);
--
2.7.4
^ permalink raw reply related
* [Bug 107296] WARNING: CPU: 0 PID: 370 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1355 dcn_bw_update_from_pplib+0x16b/0x280 [amdgpu]
From: bugzilla-daemon @ 2018-07-23 14:29 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-107296-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 2137 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=107296
--- Comment #1 from Paul Menzel <pmenzel+bugs.freedesktop@molgen.mpg.de> ---
In today’s drm-tip this is:
[ 20.149515] WARNING: CPU: 0 PID: 347 at
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1372
dcn_bw_update_from_pplib+0x16b/0x280 [amdgpu]
It looks like this is `BREAK_TO_DEBUGGER()` [1], which is defined as `#define
BREAK_TO_DEBUGGER() ASSERT(0)`.
```
/* TODO: This is not the proper way to obtain
fabric_and_dram_bandwidth, should be min(fclk, memclk) */
res = dm_pp_get_clock_levels_by_type_with_voltage(
ctx, DM_PP_CLOCK_TYPE_FCLK, &fclks);
if (res)
res = verify_clock_values(&fclks);
if (res) {
ASSERT(fclks.num_levels >= 3);
dc->dcn_soc->fabric_and_dram_bandwidth_vmin0p65 = 32 *
(fclks.data[0].clocks_in_khz / 1000.0) / 1000.0;
dc->dcn_soc->fabric_and_dram_bandwidth_vmid0p72 =
dc->dcn_soc->number_of_channels *
(fclks.data[fclks.num_levels -
(fclks.num_levels > 2 ? 3 : 2)].clocks_in_khz / 1000.0)
* ddr4_dram_factor_single_Channel / 1000.0;
dc->dcn_soc->fabric_and_dram_bandwidth_vnom0p8 =
dc->dcn_soc->number_of_channels *
(fclks.data[fclks.num_levels - 2].clocks_in_khz
/ 1000.0)
* ddr4_dram_factor_single_Channel / 1000.0;
dc->dcn_soc->fabric_and_dram_bandwidth_vmax0p9 =
dc->dcn_soc->number_of_channels *
(fclks.data[fclks.num_levels - 1].clocks_in_khz
/ 1000.0)
* ddr4_dram_factor_single_Channel / 1000.0;
} else
BREAK_TO_DEBUGGER();
```
So, either `dm_pp_get_clock_levels_by_type_with_voltage()` or
`verify_clock_values(&fclks)` returns 0.
[1]:
https://cgit.freedesktop.org/drm-tip/tree/drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c#n1372
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 3285 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v2 02/17] x86/cache: get Dhyana cache size/leaves and setup cache cpumap
From: Pu Wen @ 2018-07-23 13:20 UTC (permalink / raw)
To: tglx, bp, thomas.lendacky, mingo, hpa, peterz, tony.luck,
pbonzini, rkrcmar, boris.ostrovsky, jgross, rjw, lenb,
viresh.kumar, mchehab, trenn, shuah, JBeulich, x86
Cc: linux-kernel, linux-arch, kvm, xen-devel
In-Reply-To: <1532352037-7151-1-git-send-email-puwen@hygon.cn>
Hygon Dhyana processor has the topology extensions bit in CPUID.
With this bit kernel can get the cache info. So add support
in cpuid4_cache_lookup_regs() to get the correct cache size.
Dhyana also find num_cache_leaves via CPUID leaf 0x8000001d, so
add Hygon support 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>
---
arch/x86/include/asm/cacheinfo.h | 1 +
arch/x86/kernel/cpu/cacheinfo.c | 31 +++++++++++++++++++++++++++++--
arch/x86/kernel/cpu/cpu.h | 1 +
arch/x86/kernel/cpu/hygon.c | 3 +++
4 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/cacheinfo.h b/arch/x86/include/asm/cacheinfo.h
index e958e28..86b63c7 100644
--- a/arch/x86/include/asm/cacheinfo.h
+++ b/arch/x86/include/asm/cacheinfo.h
@@ -3,5 +3,6 @@
#define _ASM_X86_CACHEINFO_H
void cacheinfo_amd_init_llc_id(struct cpuinfo_x86 *c, int cpu, u8 node_id);
+void cacheinfo_hygon_init_llc_id(struct cpuinfo_x86 *c, int cpu, u8 node_id);
#endif /* _ASM_X86_CACHEINFO_H */
diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index 0c5fcbd..dc1b934 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -602,6 +602,10 @@ cpuid4_cache_lookup_regs(int index, struct _cpuid4_info_regs *this_leaf)
else
amd_cpuid4(index, &eax, &ebx, &ecx);
amd_init_l3_cache(this_leaf, index);
+ } else if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
+ cpuid_count(0x8000001d, index, &eax.full,
+ &ebx.full, &ecx.full, &edx);
+ amd_init_l3_cache(this_leaf, index);
} else {
cpuid_count(4, index, &eax.full, &ebx.full, &ecx.full, &edx);
}
@@ -625,7 +629,8 @@ static int find_num_cache_leaves(struct cpuinfo_x86 *c)
union _cpuid4_leaf_eax cache_eax;
int i = -1;
- if (c->x86_vendor == X86_VENDOR_AMD)
+ if (c->x86_vendor == X86_VENDOR_AMD ||
+ c->x86_vendor == X86_VENDOR_HYGON)
op = 0x8000001d;
else
op = 4;
@@ -678,6 +683,22 @@ void cacheinfo_amd_init_llc_id(struct cpuinfo_x86 *c, int cpu, u8 node_id)
}
}
+void cacheinfo_hygon_init_llc_id(struct cpuinfo_x86 *c, int cpu, u8 node_id)
+{
+ /*
+ * We may have multiple LLCs if L3 caches exist, so check if we
+ * have an L3 cache by looking at the L3 cache CPUID leaf.
+ */
+ if (!cpuid_edx(0x80000006))
+ return;
+
+ /*
+ * LLC is at the core complex level.
+ * Core complex ID is ApicId[3] for these processors.
+ */
+ per_cpu(cpu_llc_id, cpu) = c->apicid >> 3;
+}
+
void init_amd_cacheinfo(struct cpuinfo_x86 *c)
{
@@ -691,6 +712,11 @@ void init_amd_cacheinfo(struct cpuinfo_x86 *c)
}
}
+void init_hygon_cacheinfo(struct cpuinfo_x86 *c)
+{
+ num_cache_leaves = find_num_cache_leaves(c);
+}
+
void init_intel_cacheinfo(struct cpuinfo_x86 *c)
{
/* Cache sizes */
@@ -913,7 +939,8 @@ static void __cache_cpumap_setup(unsigned int cpu, int index,
int index_msb, i;
struct cpuinfo_x86 *c = &cpu_data(cpu);
- if (c->x86_vendor == X86_VENDOR_AMD) {
+ if (c->x86_vendor == X86_VENDOR_AMD ||
+ c->x86_vendor == X86_VENDOR_HYGON) {
if (__cache_amd_cpumap_setup(cpu, index, base))
return;
}
diff --git a/arch/x86/kernel/cpu/cpu.h b/arch/x86/kernel/cpu/cpu.h
index 38216f6..c2ba596 100644
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -53,6 +53,7 @@ extern u32 get_scattered_cpuid_leaf(unsigned int level,
enum cpuid_regs_idx reg);
extern void init_intel_cacheinfo(struct cpuinfo_x86 *c);
extern void init_amd_cacheinfo(struct cpuinfo_x86 *c);
+extern void init_hygon_cacheinfo(struct cpuinfo_x86 *c);
extern void detect_num_cpu_cores(struct cpuinfo_x86 *c);
extern int detect_extended_topology(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/hygon.c b/arch/x86/kernel/cpu/hygon.c
index cc296e5..0d77b91 100644
--- a/arch/x86/kernel/cpu/hygon.c
+++ b/arch/x86/kernel/cpu/hygon.c
@@ -85,6 +85,7 @@ static void hygon_get_topology(struct cpuinfo_x86 *c)
if (!err)
c->x86_coreid_bits = get_count_order(c->x86_max_cores);
+ cacheinfo_amd_init_llc_id(c, cpu, node_id);
} else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
u64 value;
@@ -315,6 +316,8 @@ static void init_hygon(struct cpuinfo_x86 *c)
srat_detect_node(c);
}
+ init_hygon_cacheinfo(c);
+
set_cpu_cap(c, X86_FEATURE_K8);
if (cpu_has(c, X86_FEATURE_XMM2)) {
--
2.7.4
^ permalink raw reply related
* [PATCH v2 09/17] x86/bugs: add lfence mitigation to spectre v2 and no meltdown for Hygon
From: Pu Wen @ 2018-07-23 13:20 UTC (permalink / raw)
To: tglx, bp, thomas.lendacky, mingo, hpa, peterz, tony.luck,
pbonzini, rkrcmar, boris.ostrovsky, jgross, rjw, lenb,
viresh.kumar, mchehab, trenn, shuah, JBeulich, x86
Cc: linux-kernel, linux-arch, kvm, xen-devel
In-Reply-To: <1532352037-7151-1-git-send-email-puwen@hygon.cn>
To share codes between AMD and Hygon to mitigate Spectre V2 Retpoline
vulnerability, rename macros SPECTRE_V2_RETPOLINE_MINIMAL_AMD to
SPECTRE_V2_RETPOLINE_MINIMAL_LFENCE, and SPECTRE_V2_CMD_RETPOLINE_AMD
to SPECTRE_V2_CMD_RETPOLINE_LFENCE.
As Hygon processors is not affected by meltdown vulnerability as AMD's,
so add exception in array cpu_no_meltdown[] for it.
Signed-off-by: Pu Wen <puwen@hygon.cn>
---
arch/x86/include/asm/nospec-branch.h | 4 ++--
arch/x86/kernel/cpu/bugs.c | 28 +++++++++++++++-------------
arch/x86/kernel/cpu/common.c | 1 +
3 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index f6f6c63..aad6b9c 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -211,9 +211,9 @@
enum spectre_v2_mitigation {
SPECTRE_V2_NONE,
SPECTRE_V2_RETPOLINE_MINIMAL,
- SPECTRE_V2_RETPOLINE_MINIMAL_AMD,
+ SPECTRE_V2_RETPOLINE_MINIMAL_LFENCE,
SPECTRE_V2_RETPOLINE_GENERIC,
- SPECTRE_V2_RETPOLINE_AMD,
+ SPECTRE_V2_RETPOLINE_LFENCE,
SPECTRE_V2_IBRS,
};
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 5c0ea39..5d0ba61 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -121,15 +121,15 @@ enum spectre_v2_mitigation_cmd {
SPECTRE_V2_CMD_FORCE,
SPECTRE_V2_CMD_RETPOLINE,
SPECTRE_V2_CMD_RETPOLINE_GENERIC,
- SPECTRE_V2_CMD_RETPOLINE_AMD,
+ SPECTRE_V2_CMD_RETPOLINE_LFENCE,
};
static const char *spectre_v2_strings[] = {
[SPECTRE_V2_NONE] = "Vulnerable",
[SPECTRE_V2_RETPOLINE_MINIMAL] = "Vulnerable: Minimal generic ASM retpoline",
- [SPECTRE_V2_RETPOLINE_MINIMAL_AMD] = "Vulnerable: Minimal AMD ASM retpoline",
+ [SPECTRE_V2_RETPOLINE_MINIMAL_LFENCE] = "Vulnerable: Minimal LFENCE ASM retpoline",
[SPECTRE_V2_RETPOLINE_GENERIC] = "Mitigation: Full generic retpoline",
- [SPECTRE_V2_RETPOLINE_AMD] = "Mitigation: Full AMD retpoline",
+ [SPECTRE_V2_RETPOLINE_LFENCE] = "Mitigation: Full LFENCE retpoline",
};
#undef pr_fmt
@@ -260,7 +260,7 @@ static const struct {
{ "off", SPECTRE_V2_CMD_NONE, false },
{ "on", SPECTRE_V2_CMD_FORCE, true },
{ "retpoline", SPECTRE_V2_CMD_RETPOLINE, false },
- { "retpoline,amd", SPECTRE_V2_CMD_RETPOLINE_AMD, false },
+ { "retpoline,lfence", SPECTRE_V2_CMD_RETPOLINE_LFENCE, false },
{ "retpoline,generic", SPECTRE_V2_CMD_RETPOLINE_GENERIC, false },
{ "auto", SPECTRE_V2_CMD_AUTO, false },
};
@@ -292,16 +292,17 @@ static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
}
if ((cmd == SPECTRE_V2_CMD_RETPOLINE ||
- cmd == SPECTRE_V2_CMD_RETPOLINE_AMD ||
+ cmd == SPECTRE_V2_CMD_RETPOLINE_LFENCE ||
cmd == SPECTRE_V2_CMD_RETPOLINE_GENERIC) &&
!IS_ENABLED(CONFIG_RETPOLINE)) {
pr_err("%s selected but not compiled in. Switching to AUTO select\n", mitigation_options[i].option);
return SPECTRE_V2_CMD_AUTO;
}
- if (cmd == SPECTRE_V2_CMD_RETPOLINE_AMD &&
+ if (cmd == SPECTRE_V2_CMD_RETPOLINE_LFENCE &&
+ boot_cpu_data.x86_vendor != X86_VENDOR_HYGON &&
boot_cpu_data.x86_vendor != X86_VENDOR_AMD) {
- pr_err("retpoline,amd selected but CPU is not AMD. Switching to AUTO select\n");
+ pr_err("retpoline,amd selected but CPU is not AMD or Hygon. Switching to AUTO select\n");
return SPECTRE_V2_CMD_AUTO;
}
@@ -352,9 +353,9 @@ static void __init spectre_v2_select_mitigation(void)
if (IS_ENABLED(CONFIG_RETPOLINE))
goto retpoline_auto;
break;
- case SPECTRE_V2_CMD_RETPOLINE_AMD:
+ case SPECTRE_V2_CMD_RETPOLINE_LFENCE:
if (IS_ENABLED(CONFIG_RETPOLINE))
- goto retpoline_amd;
+ goto retpoline_lfence;
break;
case SPECTRE_V2_CMD_RETPOLINE_GENERIC:
if (IS_ENABLED(CONFIG_RETPOLINE))
@@ -369,14 +370,15 @@ static void __init spectre_v2_select_mitigation(void)
return;
retpoline_auto:
- if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
- retpoline_amd:
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
+ retpoline_lfence:
if (!boot_cpu_has(X86_FEATURE_LFENCE_RDTSC)) {
pr_err("Spectre mitigation: LFENCE not serializing, switching to generic retpoline\n");
goto retpoline_generic;
}
- mode = retp_compiler() ? SPECTRE_V2_RETPOLINE_AMD :
- SPECTRE_V2_RETPOLINE_MINIMAL_AMD;
+ mode = retp_compiler() ? SPECTRE_V2_RETPOLINE_LFENCE :
+ SPECTRE_V2_RETPOLINE_MINIMAL_LFENCE;
setup_force_cpu_cap(X86_FEATURE_RETPOLINE_AMD);
setup_force_cpu_cap(X86_FEATURE_RETPOLINE);
} else {
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index eb4cb3e..06b3168 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -968,6 +968,7 @@ static const __initconst struct x86_cpu_id cpu_no_speculation[] = {
static const __initconst struct x86_cpu_id cpu_no_meltdown[] = {
{ X86_VENDOR_AMD },
+ { X86_VENDOR_HYGON },
{}
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 07/17] x86/pci: add Hygon PCI vendor and northbridge support
From: Pu Wen @ 2018-07-23 13:20 UTC (permalink / raw)
To: tglx, bp, thomas.lendacky, mingo, hpa, peterz, tony.luck,
pbonzini, rkrcmar, boris.ostrovsky, jgross, rjw, lenb,
viresh.kumar, mchehab, trenn, shuah, JBeulich, x86
Cc: linux-kernel, linux-arch, kvm, xen-devel
In-Reply-To: <1532352037-7151-1-git-send-email-puwen@hygon.cn>
As Hygon register its PCI Vendor ID as a new one "0x1d94", so add a new
definition PCI_VENDOR_ID_HYGON in include/linux/pci_ids.h.
Also Hygon PCI Device ID(0x1450/0x1463/0x1464) for Host bridge is added
to amd_nb.c. And it need to define new arrays for Hygon:
hygon_root_ids[], hygon_nb_misc_ids[], hygon_nb_link_ids[].
To enable Hygon north bridge support, add new variable root_ids, and
assign its value based on whether CPU vendor is AMD or Hygon. Modify
the CONFIG_AMD_NB to depends on either AMD or Hygon.
Add Hygon support in amd_postcore_init(), early_root_info_init().
Signed-off-by: Pu Wen <puwen@hygon.cn>
---
arch/x86/Kconfig | 2 +-
arch/x86/kernel/amd_nb.c | 54 +++++++++++++++++++++++++++++++++++++++++-------
arch/x86/pci/amd_bus.c | 6 ++++--
include/linux/pci_ids.h | 2 ++
4 files changed, 54 insertions(+), 10 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 887d3a7..c71e08bf 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2822,7 +2822,7 @@ endif # X86_32
config AMD_NB
def_bool y
- depends on CPU_SUP_AMD && PCI
+ depends on (CPU_SUP_AMD || CPU_SUP_HYGON) && PCI
source "drivers/pcmcia/Kconfig"
diff --git a/arch/x86/kernel/amd_nb.c b/arch/x86/kernel/amd_nb.c
index b481b95..884dd4a 100644
--- a/arch/x86/kernel/amd_nb.c
+++ b/arch/x86/kernel/amd_nb.c
@@ -20,6 +20,10 @@
#define PCI_DEVICE_ID_AMD_17H_M10H_DF_F3 0x15eb
#define PCI_DEVICE_ID_AMD_17H_M10H_DF_F4 0x15ec
+#define PCI_DEVICE_ID_HYGON_18H_ROOT 0x1450
+#define PCI_DEVICE_ID_HYGON_18H_DF_F3 0x1463
+#define PCI_DEVICE_ID_HYGON_18H_DF_F4 0x1464
+
/* Protect the PCI config register pairs used for SMN and DF indirect access. */
static DEFINE_MUTEX(smn_mutex);
@@ -61,6 +65,21 @@ static const struct pci_device_id amd_nb_link_ids[] = {
{}
};
+static const struct pci_device_id hygon_root_ids[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_HYGON, PCI_DEVICE_ID_HYGON_18H_ROOT) },
+ {}
+};
+
+const struct pci_device_id hygon_nb_misc_ids[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_HYGON, PCI_DEVICE_ID_HYGON_18H_DF_F3) },
+ {}
+};
+
+static const struct pci_device_id hygon_nb_link_ids[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_HYGON, PCI_DEVICE_ID_HYGON_18H_DF_F4) },
+ {}
+};
+
const struct amd_nb_bus_dev_range amd_nb_bus_dev_ranges[] __initconst = {
{ 0x00, 0x18, 0x20 },
{ 0xff, 0x00, 0x20 },
@@ -197,12 +216,25 @@ int amd_cache_northbridges(void)
u16 i = 0;
struct amd_northbridge *nb;
struct pci_dev *root, *misc, *link;
+ const struct pci_device_id *root_ids = NULL;
+ const struct pci_device_id *misc_ids = NULL;
+ const struct pci_device_id *link_ids = NULL;
+
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+ root_ids = amd_root_ids;
+ misc_ids = amd_nb_misc_ids;
+ link_ids = amd_nb_link_ids;
+ } else if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
+ root_ids = hygon_root_ids;
+ misc_ids = hygon_nb_misc_ids;
+ link_ids = hygon_nb_link_ids;
+ }
if (amd_northbridges.num)
return 0;
misc = NULL;
- while ((misc = next_northbridge(misc, amd_nb_misc_ids)) != NULL)
+ while ((misc = next_northbridge(misc, misc_ids)) != NULL)
i++;
if (!i)
@@ -218,11 +250,11 @@ int amd_cache_northbridges(void)
link = misc = root = NULL;
for (i = 0; i != amd_northbridges.num; i++) {
node_to_amd_nb(i)->root = root =
- next_northbridge(root, amd_root_ids);
+ next_northbridge(root, root_ids);
node_to_amd_nb(i)->misc = misc =
- next_northbridge(misc, amd_nb_misc_ids);
+ next_northbridge(misc, misc_ids);
node_to_amd_nb(i)->link = link =
- next_northbridge(link, amd_nb_link_ids);
+ next_northbridge(link, link_ids);
}
if (amd_gart_present())
@@ -263,9 +295,15 @@ bool __init early_is_amd_nb(u32 device)
{
const struct pci_device_id *id;
u32 vendor = device & 0xffff;
+ const struct pci_device_id *misc_ids = NULL;
+
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+ misc_ids = amd_nb_misc_ids;
+ else if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
+ misc_ids = hygon_nb_misc_ids;
device >>= 16;
- for (id = amd_nb_misc_ids; id->vendor; id++)
+ for (id = misc_ids; id->vendor; id++)
if (vendor == id->vendor && device == id->device)
return true;
return false;
@@ -277,7 +315,8 @@ struct resource *amd_get_mmconfig_range(struct resource *res)
u64 base, msr;
unsigned int segn_busn_bits;
- if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
+ if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
+ boot_cpu_data.x86_vendor != X86_VENDOR_HYGON)
return NULL;
/* assume all cpus from fam10h have mmconfig */
@@ -426,7 +465,8 @@ static __init void fix_erratum_688(void)
struct pci_dev *F4;
u32 val;
- if (boot_cpu_data.x86 != 0x14)
+ if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD ||
+ boot_cpu_data.x86 != 0x14)
return;
if (!amd_northbridges.num)
diff --git a/arch/x86/pci/amd_bus.c b/arch/x86/pci/amd_bus.c
index 649bdde..bfa50e6 100644
--- a/arch/x86/pci/amd_bus.c
+++ b/arch/x86/pci/amd_bus.c
@@ -93,7 +93,8 @@ static int __init early_root_info_init(void)
vendor = id & 0xffff;
device = (id>>16) & 0xffff;
- if (vendor != PCI_VENDOR_ID_AMD)
+ if (vendor != PCI_VENDOR_ID_AMD &&
+ vendor != PCI_VENDOR_ID_HYGON)
continue;
if (hb_probes[i].device == device) {
@@ -390,7 +391,8 @@ static int __init pci_io_ecs_init(void)
static int __init amd_postcore_init(void)
{
- if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
+ if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
+ boot_cpu_data.x86_vendor != X86_VENDOR_HYGON)
return 0;
early_root_info_init();
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 2950223..d0e98a9 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -511,6 +511,8 @@
#define PCI_DEVICE_ID_AMI_MEGARAID 0x9010
#define PCI_DEVICE_ID_AMI_MEGARAID2 0x9060
+#define PCI_VENDOR_ID_HYGON 0x1d94
+
#define PCI_VENDOR_ID_AMD 0x1022
#define PCI_DEVICE_ID_AMD_K8_NB 0x1100
#define PCI_DEVICE_ID_AMD_K8_NB_ADDRMAP 0x1101
--
2.7.4
^ permalink raw reply related
* [PATCH v2 11/17] x86/mce: enable Hygon support to MCE infrastructure
From: Pu Wen @ 2018-07-23 13:20 UTC (permalink / raw)
To: tglx, bp, thomas.lendacky, mingo, hpa, peterz, tony.luck,
pbonzini, rkrcmar, boris.ostrovsky, jgross, rjw, lenb,
viresh.kumar, mchehab, trenn, shuah, JBeulich, x86
Cc: linux-kernel, linux-arch, kvm, xen-devel
In-Reply-To: <1532352037-7151-1-git-send-email-puwen@hygon.cn>
Hygon machine check arch is similar to AMD family 17h. To enable the MCE
infrastructure support, add CPU vendor check for Hygon to share the code
path of AMD.
Add hygon mce init function mce_hygon_feature_init() to minimize further
maintenance effort.
Signed-off-by: Pu Wen <puwen@hygon.cn>
---
arch/x86/include/asm/mce.h | 5 +++++
arch/x86/kernel/cpu/mcheck/mce-severity.c | 3 ++-
arch/x86/kernel/cpu/mcheck/mce.c | 20 +++++++++++++++-----
3 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 8c7b3e5..0af3b0e 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -213,6 +213,11 @@ static inline void mce_amd_feature_init(struct cpuinfo_x86 *c) { }
static inline int umc_normaddr_to_sysaddr(u64 norm_addr, u16 nid, u8 umc, u64 *sys_addr) { return -EINVAL; };
#endif
+static inline void mce_hygon_feature_init(struct cpuinfo_x86 *c)
+{
+ return mce_amd_feature_init(c);
+}
+
int mce_available(struct cpuinfo_x86 *c);
bool mce_is_memory_error(struct mce *m);
diff --git a/arch/x86/kernel/cpu/mcheck/mce-severity.c b/arch/x86/kernel/cpu/mcheck/mce-severity.c
index f34d89c..44396d5 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-severity.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-severity.c
@@ -336,7 +336,8 @@ int (*mce_severity)(struct mce *m, int tolerant, char **msg, bool is_excp) =
void __init mcheck_vendor_init_severity(void)
{
- if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
mce_severity = mce_severity_amd;
}
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 8c50754..1691a8f 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -274,7 +274,8 @@ static void print_mce(struct mce *m)
{
__print_mce(m);
- if (m->cpuvendor != X86_VENDOR_AMD)
+ if (m->cpuvendor != X86_VENDOR_AMD &&
+ m->cpuvendor != X86_VENDOR_HYGON)
pr_emerg_ratelimited(HW_ERR "Run the above through 'mcelog --ascii'\n");
}
@@ -512,9 +513,9 @@ static int mce_usable_address(struct mce *m)
bool mce_is_memory_error(struct mce *m)
{
- if (m->cpuvendor == X86_VENDOR_AMD) {
+ if (m->cpuvendor == X86_VENDOR_AMD ||
+ m->cpuvendor == X86_VENDOR_HYGON) {
return amd_mce_is_memory_error(m);
-
} else if (m->cpuvendor == X86_VENDOR_INTEL) {
/*
* Intel SDM Volume 3B - 15.9.2 Compound Error Codes
@@ -543,6 +544,9 @@ static bool mce_is_correctable(struct mce *m)
if (m->cpuvendor == X86_VENDOR_AMD && m->status & MCI_STATUS_DEFERRED)
return false;
+ if (m->cpuvendor == X86_VENDOR_HYGON && m->status & MCI_STATUS_DEFERRED)
+ return false;
+
if (m->status & MCI_STATUS_UC)
return false;
@@ -1725,7 +1729,8 @@ static int __mcheck_cpu_ancient_init(struct cpuinfo_x86 *c)
*/
static void __mcheck_cpu_init_early(struct cpuinfo_x86 *c)
{
- if (c->x86_vendor == X86_VENDOR_AMD) {
+ if (c->x86_vendor == X86_VENDOR_AMD ||
+ c->x86_vendor == X86_VENDOR_HYGON) {
mce_flags.overflow_recov = !!cpu_has(c, X86_FEATURE_OVERFLOW_RECOV);
mce_flags.succor = !!cpu_has(c, X86_FEATURE_SUCCOR);
mce_flags.smca = !!cpu_has(c, X86_FEATURE_SMCA);
@@ -1766,6 +1771,9 @@ static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c)
mce_amd_feature_init(c);
break;
}
+ case X86_VENDOR_HYGON:
+ mce_hygon_feature_init(c);
+ break;
case X86_VENDOR_CENTAUR:
mce_centaur_feature_init(c);
break;
@@ -1991,12 +1999,14 @@ static void mce_disable_error_reporting(void)
static void vendor_disable_error_reporting(void)
{
/*
- * Don't clear on Intel or AMD CPUs. Some of these MSRs are socket-wide.
+ * Don't clear on Intel or AMD or Hygon CPUs. Some of these MSRs
+ * are socket-wide.
* Disabling them for just a single offlined CPU is bad, since it will
* inhibit reporting for all shared resources on the socket like the
* last level cache (LLC), the integrated memory controller (iMC), etc.
*/
if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ||
boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
return;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 04/17] x86/smpboot: smp init nodelay and no flush caches before sleep
From: Pu Wen @ 2018-07-23 13:20 UTC (permalink / raw)
To: tglx, bp, thomas.lendacky, mingo, hpa, peterz, tony.luck,
pbonzini, rkrcmar, boris.ostrovsky, jgross, rjw, lenb,
viresh.kumar, mchehab, trenn, shuah, JBeulich, x86
Cc: linux-kernel, linux-arch, kvm, xen-devel
In-Reply-To: <1532352037-7151-1-git-send-email-puwen@hygon.cn>
Dhyana use no delay in smp_quirk_init_udelay(), and return in
mwait_play_dead() as AMD does.
Signed-off-by: Pu Wen <puwen@hygon.cn>
---
arch/x86/kernel/smpboot.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index db9656e..26cb2c9 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -658,6 +658,7 @@ static void __init smp_quirk_init_udelay(void)
/* if modern processor, use no delay */
if (((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) && (boot_cpu_data.x86 == 6)) ||
+ ((boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) && (boot_cpu_data.x86 >= 0x18)) ||
((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) && (boot_cpu_data.x86 >= 0xF))) {
init_udelay = 0;
return;
@@ -1574,7 +1575,8 @@ static inline void mwait_play_dead(void)
void *mwait_ptr;
int i;
- if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
return;
if (!this_cpu_has(X86_FEATURE_MWAIT))
return;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 03/17] x86/mtrr: get MTRR number and support TOP_MEM2
From: Pu Wen @ 2018-07-23 13:20 UTC (permalink / raw)
To: tglx, bp, thomas.lendacky, mingo, hpa, peterz, tony.luck,
pbonzini, rkrcmar, boris.ostrovsky, jgross, rjw, lenb,
viresh.kumar, mchehab, trenn, shuah, JBeulich, x86
Cc: linux-kernel, linux-arch, kvm, xen-devel
In-Reply-To: <1532352037-7151-1-git-send-email-puwen@hygon.cn>
Hygon CPU have a special magic MSR way to force WB for memory >4GB,
and also support TOP_MEM2. Therefore, it is necessary to add Hygon
support in amd_special_default_mtrr().
The MtrrFixDramModEn bit on Hygon platform should also be set to 1 during
BIOS initialization of the fixed MTRRs, then cleared to 0 for operation.
The number of variable MTRRs for Hygon is 2 as AMD's.
Signed-off-by: Pu Wen <puwen@hygon.cn>
---
arch/x86/kernel/cpu/mtrr/cleanup.c | 3 ++-
arch/x86/kernel/cpu/mtrr/generic.c | 3 ++-
arch/x86/kernel/cpu/mtrr/mtrr.c | 2 +-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
index 765afd5..3668c5d 100644
--- a/arch/x86/kernel/cpu/mtrr/cleanup.c
+++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
@@ -831,7 +831,8 @@ int __init amd_special_default_mtrr(void)
{
u32 l, h;
- if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
+ if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
+ boot_cpu_data.x86_vendor != X86_VENDOR_HYGON)
return 0;
if (boot_cpu_data.x86 < 0xf)
return 0;
diff --git a/arch/x86/kernel/cpu/mtrr/generic.c b/arch/x86/kernel/cpu/mtrr/generic.c
index e12ee86..71f868f 100644
--- a/arch/x86/kernel/cpu/mtrr/generic.c
+++ b/arch/x86/kernel/cpu/mtrr/generic.c
@@ -49,7 +49,8 @@ static inline void k8_check_syscfg_dram_mod_en(void)
{
u32 lo, hi;
- if (!((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
+ if (!((boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) &&
(boot_cpu_data.x86 >= 0x0f)))
return;
diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.c b/arch/x86/kernel/cpu/mtrr/mtrr.c
index 9a19c80..507039c 100644
--- a/arch/x86/kernel/cpu/mtrr/mtrr.c
+++ b/arch/x86/kernel/cpu/mtrr/mtrr.c
@@ -127,7 +127,7 @@ static void __init set_num_var_ranges(void)
if (use_intel())
rdmsr(MSR_MTRRcap, config, dummy);
- else if (is_cpu(AMD))
+ else if (is_cpu(AMD) || is_cpu(HYGON))
config = 2;
else if (is_cpu(CYRIX) || is_cpu(CENTAUR))
config = 8;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 14/17] driver/acpi: enable Hygon support to ACPI driver
From: Pu Wen @ 2018-07-23 13:20 UTC (permalink / raw)
To: tglx, bp, thomas.lendacky, mingo, hpa, peterz, tony.luck,
pbonzini, rkrcmar, boris.ostrovsky, jgross, rjw, lenb,
viresh.kumar, mchehab, trenn, shuah, JBeulich, x86
Cc: linux-kernel, linux-arch, kvm, xen-devel
In-Reply-To: <1532352037-7151-1-git-send-email-puwen@hygon.cn>
For Dhyana processors have NONSTOP TSC feature, so enable the support
to ACPI driver.
Signed-off-by: Pu Wen <puwen@hygon.cn>
---
drivers/acpi/acpi_pad.c | 1 +
drivers/acpi/processor_idle.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index 552c1f7..a47676a 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -70,6 +70,7 @@ static void power_saving_mwait_init(void)
#if defined(CONFIG_X86)
switch (boot_cpu_data.x86_vendor) {
+ case X86_VENDOR_HYGON:
case X86_VENDOR_AMD:
case X86_VENDOR_INTEL:
/*
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index abb559c..b2131c4 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -205,6 +205,7 @@ static void lapic_timer_state_broadcast(struct acpi_processor *pr,
static void tsc_check_state(int state)
{
switch (boot_cpu_data.x86_vendor) {
+ case X86_VENDOR_HYGON:
case X86_VENDOR_AMD:
case X86_VENDOR_INTEL:
case X86_VENDOR_CENTAUR:
--
2.7.4
^ permalink raw reply related
* [PATCH v2 06/17] x86/nops: init ideal_nops for Hygon
From: Pu Wen @ 2018-07-23 13:20 UTC (permalink / raw)
To: tglx, bp, thomas.lendacky, mingo, hpa, peterz, tony.luck,
pbonzini, rkrcmar, boris.ostrovsky, jgross, rjw, lenb,
viresh.kumar, mchehab, trenn, shuah, JBeulich, x86
Cc: linux-kernel, linux-arch, kvm, xen-devel
In-Reply-To: <1532352037-7151-1-git-send-email-puwen@hygon.cn>
The ideal_nops for Dhyana processors should be p6_nops.
Signed-off-by: Pu Wen <puwen@hygon.cn>
---
arch/x86/kernel/alternative.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index a481763..8f4925b 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -222,6 +222,10 @@ void __init arch_init_ideal_nops(void)
}
break;
+ case X86_VENDOR_HYGON:
+ ideal_nops = p6_nops;
+ return;
+
case X86_VENDOR_AMD:
if (boot_cpu_data.x86 > 0xf) {
ideal_nops = p6_nops;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 08/17] x86/apic: add modern APIC support for Hygon
From: Pu Wen @ 2018-07-23 13:20 UTC (permalink / raw)
To: tglx, bp, thomas.lendacky, mingo, hpa, peterz, tony.luck,
pbonzini, rkrcmar, boris.ostrovsky, jgross, rjw, lenb,
viresh.kumar, mchehab, trenn, shuah, JBeulich, x86
Cc: linux-kernel, linux-arch, kvm, xen-devel
In-Reply-To: <1532352037-7151-1-git-send-email-puwen@hygon.cn>
Hygon processors use modern APIC, so just return in modern_apic() and
sync_Arb_IDs(). And should break in switch case in detect_init_API().
Signed-off-by: Pu Wen <puwen@hygon.cn>
---
arch/x86/kernel/apic/apic.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 2aabd4c..d8b7ac1 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -223,6 +223,11 @@ static int modern_apic(void)
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
boot_cpu_data.x86 >= 0xf)
return 1;
+
+ /* Hygon systems use modern APIC */
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
+ return 1;
+
return lapic_get_version() >= 0x14;
}
@@ -1207,9 +1212,11 @@ void __init sync_Arb_IDs(void)
{
/*
* Unsupported on P4 - see Intel Dev. Manual Vol. 3, Ch. 8.6.1 And not
- * needed on AMD.
+ * needed on AMD or Hygon.
*/
- if (modern_apic() || boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+ if (modern_apic() ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
return;
/*
@@ -1908,6 +1915,8 @@ static int __init detect_init_APIC(void)
(boot_cpu_data.x86 >= 15))
break;
goto no_apic;
+ case X86_VENDOR_HYGON:
+ break;
case X86_VENDOR_INTEL:
if (boot_cpu_data.x86 == 6 || boot_cpu_data.x86 == 15 ||
(boot_cpu_data.x86 == 5 && boot_cpu_has(X86_FEATURE_APIC)))
--
2.7.4
^ permalink raw reply related
* [PATCH v2 05/17] x86/perfctr: return perf counter and event selection bit offset
From: Pu Wen @ 2018-07-23 13:20 UTC (permalink / raw)
To: tglx, bp, thomas.lendacky, mingo, hpa, peterz, tony.luck,
pbonzini, rkrcmar, boris.ostrovsky, jgross, rjw, lenb,
viresh.kumar, mchehab, trenn, shuah, JBeulich, x86
Cc: linux-kernel, linux-arch, kvm, xen-devel
In-Reply-To: <1532352037-7151-1-git-send-email-puwen@hygon.cn>
Hygon Dhyana shares similar perfctr arch with AMD family 17h.
It returns the bit offset of the performance counter register and the
event selection register for Hygon CPU in the similar way as AMD does.
Signed-off-by: Pu Wen <puwen@hygon.cn>
---
arch/x86/kernel/cpu/perfctr-watchdog.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/x86/kernel/cpu/perfctr-watchdog.c b/arch/x86/kernel/cpu/perfctr-watchdog.c
index d389083..df46708 100644
--- a/arch/x86/kernel/cpu/perfctr-watchdog.c
+++ b/arch/x86/kernel/cpu/perfctr-watchdog.c
@@ -50,6 +50,10 @@ static inline unsigned int nmi_perfctr_msr_to_bit(unsigned int msr)
if (msr >= MSR_F15H_PERF_CTR)
return (msr - MSR_F15H_PERF_CTR) >> 1;
return msr - MSR_K7_PERFCTR0;
+ case X86_VENDOR_HYGON:
+ if (msr >= MSR_F15H_PERF_CTR)
+ return (msr - MSR_F15H_PERF_CTR) >> 1;
+ return msr - MSR_K7_PERFCTR0;
case X86_VENDOR_INTEL:
if (cpu_has(&boot_cpu_data, X86_FEATURE_ARCH_PERFMON))
return msr - MSR_ARCH_PERFMON_PERFCTR0;
@@ -78,6 +82,10 @@ static inline unsigned int nmi_evntsel_msr_to_bit(unsigned int msr)
if (msr >= MSR_F15H_PERF_CTL)
return (msr - MSR_F15H_PERF_CTL) >> 1;
return msr - MSR_K7_EVNTSEL0;
+ case X86_VENDOR_HYGON:
+ if (msr >= MSR_F15H_PERF_CTL)
+ return (msr - MSR_F15H_PERF_CTL) >> 1;
+ return msr - MSR_K7_EVNTSEL0;
case X86_VENDOR_INTEL:
if (cpu_has(&boot_cpu_data, X86_FEATURE_ARCH_PERFMON))
return msr - MSR_ARCH_PERFMON_EVENTSEL0;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 0/6] Symbol namespaces
From: Arnd Bergmann @ 2018-07-23 14:28 UTC (permalink / raw)
To: Martijn Coenen
Cc: Linux Kernel Mailing List, Masahiro Yamada, Michal Marek,
Geert Uytterhoeven, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
the arch/x86 maintainers, Alan Stern, Greg Kroah-Hartman,
Oliver Neukum, Jessica Yu, Stephen Boyd, Philippe Ombredanne,
Kate Stewart, Sam Ravnborg, Linux Kbuild mailing list, linux-m68k
In-Reply-To: <20180716122125.175792-1-maco@android.com>
On Mon, Jul 16, 2018 at 2:21 PM, Martijn Coenen <maco@android.com> wrote:
> As of Linux 4.17, there are more than 30000 exported symbols
> in the kernel. There seems to be some consensus amongst
> kernel devs that the export surface is too large, and hard
> to reason about.
>
> Generally, these symbols fall in one of these categories:
> 1) Symbols actually meant for drivers
> 2) Symbols that are only exported because functionality is
> split over multiple modules, yet they really shouldn't
> be used by modules outside of their own subsystem
> 3) Symbols really only meant for in-tree use
>
> When module developers try to upstream their code, it
> regularly turns out that they are using exported symbols
> that they really shouldn't be using. This problem is even
> bigger for drivers that are currently out-of-tree, which
> may be using many symbols that they shouldn't be using,
> and that break when those symbols are removed or modified.
>
> This patch allows subsystem maintainers to partition their
> exported symbols into separate namespaces, and module
> authors to import such namespaces only when needed.
>
> This allows subsystem maintainers to more easily limit
> availability of these namespaced symbols to other parts of
> the kernel. It can also be used to partition the set of
> exported symbols for documentation purposes; for example,
> a set of symbols that is really only used for debugging
> could be in a "SUBSYSTEM_DEBUG" namespace.
This looks nice. I don't want to overload you with additional
requests, but it might be good to think about how this can
be taken further, if we want to actually convert large
parts of the kernel to it. I have two ideas:
- It would be nice to have a simple mechanism in Kconfig
to put all symbols in a module into a namespace that is
derived from KBUILD_MODNAME, to avoid having to
annotate every symbol separately. This could be similar
to how we ended up dealing with EXPORT_NO_SYMBOLS
in the linux-2.4 days, with the goal of eventually having
a namespace for each symbol. Similarly, we could pass
a number of default namespaces through the Makefile,
e.g. if we have a directory that has lots of drivers that all
import the symbols from a common subsystem module.
- If this is possible to implement, it would be great to have
a way to limit the globally visible symbols in a module
to the ones that are explicitly exported even when a that
module is built-in rather than loadable. Not sure how this
is best done though. A couple of things can be done with
objcopy, or possibly by reintroducing partial linking (which
was removed not too long ago).
Arnd
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.