search for: generic_identifi

Background: Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture between AMD and Haiguang Information Technology Co.,Ltd., aims at providing high performance x86 processor for China server market. Its first generation processor codename is Dhyana, which originates from AMD technology and shares most of the architecture with AMD's family 17h, but with different

The iommu is enabled by default when xen is booting and later disabled in iommu_setup() when no iommu is present. But under some circumstances iommu-code can be called before iommu_setup() is processed. If there is no iommu available xen crashes. This can happen for example when panic(...) is called that got introduced with patch "x86-64: detect processors subject to AMD erratum #121 and

playing with hdt on a soekris 4801, Im getting HUGE delays in cpu_detect. I added some timing code, heres what Im seeing ACPI: Detecting 0 mS in detect_acpi MEMORY: Detecting 0 mS in detect_memory DMI: Detecting 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

playing with hdt on a soekris 4801, Im getting HUGE delays in cpu_detect. I added some timing code, heres what Im seeing ACPI: Detecting 0 mS in detect_acpi MEMORY: Detecting 0 mS in detect_memory DMI: Detecting 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

Hi, When testing syslinux on Hygon Dhyana processor, there are some information as follows: boot: cpuidtest.c32 Vendor = Unknown Vendor ... boot: ifcpu.c32 debug multicore multicore : 1 cores on this system After adding support for Hygon Dhyana processor, the info- rmation is correct: boot: cpuidtest.c32 Vendor = Hygon ... boot: ifcpu.c32 debug multicore multicore : 64 cores on this

When attempting to build Xen on x86_64 FC4 platform, using the May 26 22:03 xen-unstable-src.tgz and pulling the latest BK tree: gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Wall -Werror -Wno-pointer-arith -pipe -I/tmp/xen- unstable/xen/include -I/tmp/x en-unstable/xen/include/asm-x86/mach- generic -I/tmp/xen-unstable/xen/include/asm -x86/mach-default -O3 -

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,

Xen is crashing for me since version 4.1.3 during boot on a AMD machine. This happens since patch "x86-64: detect processors subject to AMD erratum #121 and refuse to boot." Instead of the actual panic-message from the patch the following stacktrace appears (i typed it down from screen, so it might contain typos) find_iommu_for_device amd_iommu_ioapic_update_ire timer_interrupt

The last 32-bit user of stuff under CONFIG_PARAVIRT_XXL is gone. Remove 32-bit specific parts. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/entry/vdso/vdso32/vclock_gettime.c | 1 + arch/x86/include/asm/paravirt.h | 92 +++------------------ arch/x86/include/asm/paravirt_types.h | 21 ----- arch/x86/include/asm/pgtable-3level_types.h | 5 --

The last 32-bit user of stuff under CONFIG_PARAVIRT_XXL is gone. Remove 32-bit specific parts. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/entry/vdso/vdso32/vclock_gettime.c | 1 + arch/x86/include/asm/paravirt.h | 120 ++------------------ arch/x86/include/asm/paravirt_types.h | 21 ---- arch/x86/include/asm/pgtable-3level_types.h | 5 -

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

Instead of using six globally visible paravirt ops structures combine them in a single structure, keeping the original structures as sub-structures. This avoids the need to assemble struct paravirt_patch_template at runtime on the stack each time apply_paravirt() is being called (i.e. when loading a module). Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/hyperv/mmu.c

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,