search for: generic_identify

...pu_devs[X86_VENDOR_RISE] = &rise_cpu_dev; cpu_devs[X86_VENDOR_TRANSMETA] = &transmeta_cpu_dev; cpu_devs[X86_VENDOR_NSC] = &nsc_cpu_dev; + cpu_devs[X86_VENDOR_HYGON] = &hygon_cpu_dev; cpu_devs[X86_VENDOR_UNKNOWN] = &unknown_cpu_dev; } @@ -389,6 +395,7 @@ void generic_identify(struct cpuinfo_x86 *c) /* Detecting the number of cores */ switch (c->x86_vendor) { case X86_VENDOR_AMD: + case X86_VENDOR_HYGON: if (xlvl >= 0x80000008) { c->x86_num_cores = (cpuid_ecx(0x80000008) & 0xff) + 1; if (c->x86_num_cores & (c->x86_nu...

...do_IRQ printk_start_of_line acpi_os_printf io_apic_write __ioapic_write_entry ioapic_write_entry __clear_IO_APIC_pin clear_IO_APIC disable_IO_APIC __stop_this_cpu smp_send_stop machine_restart panic tasklet_schedule_on_cpu display_cacheinfo init_amd generic_identify identify_cpu _start_xen _high_start This patch fixes this by keeping the iommu disabled until iommu_setup() is entered. Signed-off-by: Ronny Hegewald@online.de --- xen/drivers/passthrough/iommu.c.org 2012-10-05 03:38:33.000000000 +0000 +++ xen/drivers/passthrough/iommu.c 2012-10-17 2...

...g Table DMI: ERROR ! Table not found ! DMI: Many hardware components will not be detected ! 55 mS in detect_dmi CPU: Detecting 0 mS in get_cpu_vendor 0 mS in "intel cpu level check" 0 mS in "amd cpu check" 0 mS in "core check" 0 mS in detect_cache 0 mS in generic_identify sizeof(cpu->vendor): 48 sizeof(cpu->model): 48 0 mS in "family-vendor-model-stepping" 416445 mS in "family-vendor strings" 416445 mS in "cores-cachesizes" 416445 mS in set_generic_info 416445 mS in set_cpu_flags 416500 mS in cpu_detect DISKS: Detectin...

...g Table DMI: ERROR ! Table not found ! DMI: Many hardware components will not be detected ! 55 mS in detect_dmi CPU: Detecting 0 mS in get_cpu_vendor 0 mS in "intel cpu level check" 0 mS in "amd cpu check" 0 mS in "core check" 0 mS in detect_cache 0 mS in generic_identify sizeof(cpu->vendor): 48 sizeof(cpu->model): 48 0 mS in "family-vendor-model-stepping" 416445 mS in "family-vendor strings" 416445 mS in "cores-cachesizes" 416445 mS in set_generic_info 416445 mS in set_cpu_flags 416500 mS in cpu_detect DISKS: Detectin...

...pu_devs[X86_VENDOR_RISE] = &rise_cpu_dev; cpu_devs[X86_VENDOR_TRANSMETA] = &transmeta_cpu_dev; cpu_devs[X86_VENDOR_NSC] = &nsc_cpu_dev; + cpu_devs[X86_VENDOR_HYGON] = &hygon_cpu_dev; cpu_devs[X86_VENDOR_UNKNOWN] = &unknown_cpu_dev; } @@ -389,6 +395,7 @@ void generic_identify(struct cpuinfo_x86 *c) /* Detecting the number of cores */ switch (c->x86_vendor) { case X86_VENDOR_AMD: + case X86_VENDOR_HYGON: if (xlvl >= 0x80000008) { c->x86_num_cores = (cpuid_ecx(0x80000008) & 0xff) + 1; if (c->x86_num_cores & (c->x86_nu...

...ning: pointer targets in passing argument 3 of ‘cpuid’ diff er in signedness cpu/common.c:209: warning: pointer targets in passing argument 4 of ‘cpuid’ diff er in signedness cpu/common.c:209: warning: pointer targets in passing argument 5 of ‘cpuid’ diff er in signedness cpu/common.c: In function ‘generic_identify’: cpu/common.c:241: warning: pointer targets in passing argument 2 of ‘cpuid’ diff er in signedness cpu/common.c:241: warning: pointer targets in passing argument 3 of ‘cpuid’ diff er in signedness cpu/common.c:241: warning: pointer targets in passing argument 4 of ‘cpuid’ diff er in signedness cpu...

Only call CPUID function 4 if cpuid_level indicates its availability. Signed-off-by: Sebastian Herbszt <herbszt at gmx.de> diff --git a/com32/gpllib/cpuid.c b/com32/gpllib/cpuid.c index fa21204..f33e895 100644 --- a/com32/gpllib/cpuid.c +++ b/com32/gpllib/cpuid.c @@ -232,8 +232,10 @@ void generic_identify(struct cpuinfo_x86 *c) } break; case X86_VENDOR_INTEL: - cpuid(0x4, &eax, &ebx, &ecx, &edx); - c->x86_num_cores = ((eax & 0xfc000000) >> 26) + 1; + if (c->cpuid_level >= 0x00000004) { + cpuid(0x4, &eax, &ebx, &ecx, &edx); + c->x...

...apic_update_ire timer_interrupt enable_8259_A_irq do_IRQ printk_start_of_line acpi_os_printf io_apic_write __ioapic_write_entry ioapic_write_entry __clear_IO_APIC_pin clear_IO_APIC disable_IO_APIC __stop_this_cpu smp_send_stop machine_restart panic tasklet_schedule_on_cpu display_cacheinfo init_amd generic_identify identify_cpu _start_xen _high_start Panic on CPU 0: Xen BUG at pci_amd_iommu.c:33 ===== The patch in the next mail fixes the problem for me and the intended panic- message appears.

...pl() 0 -#endif - #define IDT_ENTRIES 256 #define NUM_EXCEPTION_VECTORS 32 diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 965474d78cef..ca89cea31e81 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1412,15 +1412,7 @@ static void generic_identify(struct cpuinfo_x86 *c) * ESPFIX issue, we can change this. */ #ifdef CONFIG_X86_32 -# ifdef CONFIG_PARAVIRT_XXL - do { - extern void native_iret(void); - if (pv_ops.cpu.iret == native_iret) - set_cpu_bug(c, X86_BUG_ESPFIX); - } while (0); -# else set_cpu_bug(c, X86_BUG_ESPFIX); -# endi...

...pl() 0 -#endif - #define IDT_ENTRIES 256 #define NUM_EXCEPTION_VECTORS 32 diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index c5d6f17d9b9d..8aa20bc2f1ca 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1413,15 +1413,7 @@ static void generic_identify(struct cpuinfo_x86 *c) * ESPFIX issue, we can change this. */ #ifdef CONFIG_X86_32 -# ifdef CONFIG_PARAVIRT_XXL - do { - extern void native_iret(void); - if (pv_ops.cpu.iret == native_iret) - set_cpu_bug(c, X86_BUG_ESPFIX); - } while (0); -# else set_cpu_bug(c, X86_BUG_ESPFIX); -# endi...

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

..._save_fl, paravirt_patch_template, pv_irq_ops.save_fl); #endif BLANK(); #endif diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index eb4cb3efd20e..3893df059174 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1225,7 +1225,7 @@ static void generic_identify(struct cpuinfo_x86 *c) # ifdef CONFIG_PARAVIRT do { extern void native_iret(void); - if (pv_cpu_ops.iret == native_iret) + if (pv_ops.pv_cpu_ops.iret == native_iret) set_cpu_bug(c, X86_BUG_ESPFIX); } while (0); # else diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vm...

A lot of cleanup after removal of 32-bit Xen PV guest support in paravirt code. Changes in V4: - dropped patches 1-3, as already committed - addressed comments to V3 - added new patches 5+6 Changes in V3: - addressed comments to V2 - split patch 1 into 2 patches - new patches 3 and 7 Changes in V2: - rebase to 5.8 kernel - addressed comments to V1 - new patches 3 and 4 Juergen Gross (6):

This series removes some no longer needed stuff from paravirt infrastructure and puts large quantities of paravirt ops under a new config option PARAVIRT_XXL which is selected by XEN_PV only. A pvops kernel without XEN_PV being configured is about 2.5% smaller with this series applied. tip commit 5800dc5c19f34e6e03b5adab1282535cb102fafd ("x86/paravirt: Fix spectre-v2 mitigations for

This series removes some no longer needed stuff from paravirt infrastructure and puts large quantities of paravirt ops under a new config option PARAVIRT_XXL which is selected by XEN_PV only. A pvops kernel without XEN_PV being configured is about 2.5% smaller with this series applied. tip commit 5800dc5c19f34e6e03b5adab1282535cb102fafd ("x86/paravirt: Fix spectre-v2 mitigations for

Today paravirtualization is a all-or-nothing game: either a kernel is compiled with no paravirtualization support at all, or it is supporting paravirtualized environments like Xen pv-guests or lguest additionally to some paravirtualized tuning for KVM, Hyperv, VMWare or Xen HVM-guests. As support of pv-guests requires quite intrusive pv-hooks (e.g. all access functions to page table entries,