search for: x86_vendor_amd

...fo_x86 *c = &current_cpu_data; if ( (power = processor_powers[smp_processor_id()]) == NULL ) goto default_halt; @@ -601,6 +602,23 @@ static void acpi_dead_idle(void) mb(); __mwait(cx->address, 0); } + } + else if ( c->x86_vendor == X86_VENDOR_AMD && + cx->entry_method == ACPI_CSTATE_EM_SYSIO ) + { + /* Intel prefers not to use SYSIO */ + + /* Avoid references to shared data after the cache flush */ + u32 address = cx->address; + u32 pmtmr_ioport_local = pmtmr_ioport; + + wbin...

...6_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_num_cores - 1)) -- 2.17.1

...core/smpboot.c Fri Feb 29 10:29:13 2008 +0000 +++ b/drivers/xen/core/smpboot.c Fri Feb 29 12:54:47 2008 -0600 @@ -276,7 +276,8 @@ void __init smp_prepare_cpus(unsigned in cpu_2_logical_apicid[0] = 0; x86_cpu_to_apicid[0] = 0; - set_x86_acpiid_to_apicid(0, 0); + if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) + set_x86_acpiid_to_apicid(0, 0); current_thread_info()->cpu = 0; @@ -325,7 +326,8 @@ void __init smp_prepare_cpus(unsigned in cpu_2_logical_apicid[cpu] = cpu; x86_cpu_to_apicid[cpu] = cpu; - set_x86_acpiid_to_apicid(cpu, cpu); + if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)...

These two patches provide the neccessary infrastructure changes for the processor-passthru driver [www.spinics.net/lists/linux-acpi/msg34655.html] to properly function. The first one is quite easy - we just modprobe the processor-passthru driver. The second allows it to work under AMD machines by exposing the PM RDMSR to dom0. It has been tested with 2.6.32 kernel as well to make sure it does

The first patch really isn''t as much of a follow-up than what triggered the security issues to be noticed in the first place. 1: x86: preserve FPU selectors for 32-bit guest code 2: x86: fix XCR0 handling 3: x86/xsave: adjust state management 4: x86/fxsave: bring in line with recent xsave adjustments The first two I would see as candidates for 4.3 (as well as subsequent backporting,

...6_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_num_cores - 1)) -- 2.17.1

There has been some progress, but still no joy. Definitely not intended for inclusion at this point. Tim, Wei, I added a Xen command line toggle to disable IOMMU and P2M table sharing. Tim, I verified that changes to p2m-pt.c don''t break shadow mode (64bit hypervisor and Win 7 guest). Hongkaixing, I incorporated your suggestion in patch 2, so I should add your Signed-off-by eventually.

Hi, This series corresponds do older patches in the paravirt series that was neither already applied, nor I will touch again. In general, they do not touch code that can be unified (at least, without being the unification a big problem on its own). They passed through this list a lot of times, so I feel them ready for inclusion, unless someone opposes. As with the other patches, they apply to

Hi, This series corresponds do older patches in the paravirt series that was neither already applied, nor I will touch again. In general, they do not touch code that can be unified (at least, without being the unification a big problem on its own). They passed through this list a lot of times, so I feel them ready for inclusion, unless someone opposes. As with the other patches, they apply to

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Hi all, This series adds a new microcode driver for Xen. The Xen hypervisor can deal with all the low-level details of doing a microcode update (Intel vs AMD, doing all the physical CPUs present on the system, current and future, etc), so all the driver has to do is make a hypercall to upload the microcode into Xen. This only

..._vendor ) + { + case X86_VENDOR_INTEL: + /* SYSENTER entry. */ + wrmsrl(MSR_IA32_SYSENTER_ESP, (unsigned long)stack_bottom); + wrmsrl(MSR_IA32_SYSENTER_EIP, (unsigned long)sysenter_entry); + wrmsr(MSR_IA32_SYSENTER_CS, __HYPERVISOR_CS, 0); + break; + case X86_VENDOR_AMD: + /* Trampoline for SYSCALL entry from compatibility mode. */ + stack = (char *)L1_CACHE_ALIGN((unsigned long)stack); + wrmsrl(MSR_CSTAR, (unsigned long)stack); + stack += write_stack_trampoline(stack, stack_bottom, FLAT_USER_CS32); + break; + default: +...