similar to: [PATCH] Fixing mwait usage when doing cpu offline

# HG changeset patch # User Boris Ostrovsky <boris.ostrovsky@amd.com> # Date 1330642361 -3600 # Node ID 99df5c6b2964ceaa73651d7bc02fb1ae820f7691 # Parent a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9 x86: Use deep C states for off-lined CPUs Currently when a core is taken off-line it is placed in C1 state (unless MONITOR/MWAIT is used). This patch allows a core to go to deeper C states

It has never been used for anything, and Linux 3.7 doesn''t propagate this information anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- Konrad, on the pv-ops side it may be better to pass zero rather than leaving the field completely uninitialized. --- a/xen/arch/x86/acpi/cpu_idle.c +++ b/xen/arch/x86/acpi/cpu_idle.c @@ -935,7 +935,6 @@ static void set_cx( }

hi, i386 vcpu hotplug seems to work reliably but x86_64 does not and i think i have discovered why. in x86-64, a cpu within a domu can be removed with vcpu-set but subsequent calls do nothing. after xenwatch_thread grabs the event triggered by the write to the store, it calls the registered handler and never comes back. eventually, __cpu_die in drivers/xen/core/smpboot.c spins while waiting

I am trying to experiment with lhype on a 32bit Intel box and when I launch a guest I get the following oops message: ----------- invalid opcode: 0000 [#1] Modules linked in: CPU: 0 EIP: 0061:[<c0101223>] Not tainted VLI EFLAGS: 00010246 (2.6.20-rc2 #1) EIP is at mwait_idle_with_hints+0x1e/0x3a eax: c03c8008 ebx: 00000000 ecx: 00000000 edx: 00000000 esi: 00000000 edi:

I am trying to experiment with lhype on a 32bit Intel box and when I launch a guest I get the following oops message: ----------- invalid opcode: 0000 [#1] Modules linked in: CPU: 0 EIP: 0061:[<c0101223>] Not tainted VLI EFLAGS: 00010246 (2.6.20-rc2 #1) EIP is at mwait_idle_with_hints+0x1e/0x3a eax: c03c8008 ebx: 00000000 ecx: 00000000 edx: 00000000 esi: 00000000 edi:

Greetings, I''ve been experiencing problems with HTB where the whole machine locks up. This usually happens when the whole qdisc is being removed and occasionally when a leaf is being removed. Common is that it always happens when some sort of removal is in progress. Console output I have captured is at the end of this message. The same behavior exists from vanilla 2.6.19.7 and above.

From: Joerg Roedel <jroedel at suse.de> Add a play_dead handler when running under SEV-ES. This is needed because the hypervisor can't deliver an SIPI request to restart the AP. Instead the kernel has to issue a VMGEXIT to halt the VCPU. When the hypervisor would deliver and SIPI is wakes up the VCPU instead. Signed-off-by: Joerg Roedel <jroedel at suse.de> ---

From: Joerg Roedel <jroedel at suse.de> For SEV-ES this entry point will be used for restarting APs after they have been offlined. Remove the '0' from the name to reflect that. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/include/asm/cpu.h | 2 +- arch/x86/kernel/head_32.S | 4 ++-- arch/x86/kernel/head_64.S | 6 +++--- arch/x86/kernel/smpboot.c | 4 ++--

From: Joerg Roedel <jroedel at suse.de> For SEV-ES this entry point will be used for restarting APs after they have been offlined. Remove the '0' from the name to reflect that. Signed-off-by: Joerg Roedel <jroedel at suse.de> Reviewed-by: Kees Cook <keescook at chromium.org> Link: https://lore.kernel.org/r/20200724160336.5435-72-joro at 8bytes.org ---

Fix reboot to work with the VMI. We must support fallback to the standard BIOS reboot mechanism. Turns out that this is required by kexec, and a good idea for native hardware. We simply insert the NOP VMI reboot hook before calling the BIOS reboot. While here, fix SMP reboot issues as well. The problem is the halt() macro in VMI has been defined to be equivalent to safe_halt(), which enables

Fix reboot to work with the VMI. We must support fallback to the standard BIOS reboot mechanism. Turns out that this is required by kexec, and a good idea for native hardware. We simply insert the NOP VMI reboot hook before calling the BIOS reboot. While here, fix SMP reboot issues as well. The problem is the halt() macro in VMI has been defined to be equivalent to safe_halt(), which enables

Current xen-linux (2.6.18) not include support for Cx MWAIT entry method. Back port from latest Linux kernel (already there since 2.6.23). Without this patch, _CST method couldn''t get C states with FFH address space type. Signed-off-by: Wei Gang <gang.wei@intel.com> Jimmy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Matching a similar change in Linux 3.7-rc. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/cpu/mwait-idle.c +++ b/xen/arch/x86/cpu/mwait-idle.c @@ -365,6 +365,7 @@ static struct intel_idle_id { ICPU(0x2a, snb), ICPU(0x2d, snb), ICPU(0x3a, ivb), + ICPU(0x3e, ivb), {} }; _______________________________________________ Xen-devel mailing list

Hi, Keir, Thanks for checking in cpu online/offline support. Another thought inspired by Kevin, due to the time sequence that different cpus enter the stop machine context, there is a small window that some kind of softirqs (say softirq_A) are issued to the dying cpu right after the dying cpu has already handled softirq_A in do_softirq before entering stop_machine softirq. So this softirq_A

On Tue, Jan 26, 2016 at 01:37:38PM -0800, H. Peter Anvin wrote: > On 01/26/16 00:20, Michael S. Tsirkin wrote: > > On Tue, Jan 12, 2016 at 02:25:24PM -0800, H. Peter Anvin wrote: > > > > Hi hpa, > > Any luck getting some feedback on this one? > > > > Yes. What we know so far is that *most* cases it will work, but there > are apparently a few corner

On Tue, Jan 26, 2016 at 01:37:38PM -0800, H. Peter Anvin wrote: > On 01/26/16 00:20, Michael S. Tsirkin wrote: > > On Tue, Jan 12, 2016 at 02:25:24PM -0800, H. Peter Anvin wrote: > > > > Hi hpa, > > Any luck getting some feedback on this one? > > > > Yes. What we know so far is that *most* cases it will work, but there > are apparently a few corner

The xen_play_dead is an undead function. When the vCPU is told to offline it ends up calling xen_play_dead wherin it calls the VCPUOP_down hypercall which offlines the vCPU. However, when the vCPU is onlined back, it resumes execution right after VCPUOP_down hypercall. That was OK (albeit the API for play_dead assumes that the CPU stays dead and never returns) but with commit 4b0c0f294 (tick:

Hi, I've been avoiding investigating this issue for a while; I used to revert to a previously compiled version of zaptel & a previous kernel (as at some point I think I stopped being able to compile the older zaptel against the newer kernels) and all was well. However I've now upgraded kernels again and it seems silly to hide from the problem - here goes, let's try and fix it! At

Patch 1 removes CONFIG_SMP Patch 2 removes separate smp_{,r,w}mb()s as a result of patch 1 Patch 4 removes __ia64__ defines from the x86 arch tree Patch 3 is related to patch 4 and changes the VIOAPIC to emulate version 0x20 as a performance gain. It preceeds Patch 4 so as to be more clear about the functional change. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

What is the point of specifying "current" as the address to monitor? The memory location of interest really is irq_stat[cpu].__softirq_pending, and if that was used it would then also be possible to actually avoid sending IPIs when monitor/mwait are in use, as is being done on Linux. Jan _______________________________________________ Xen-devel mailing list