similar to: [PATCH 6/10] Allow vcpu to pause self

Add SMP support to Xen host S3 Signed-off-by Kevin Tian <kevin.tian@intel.com> diff -r 1539f5a2b3ba xen/arch/x86/acpi/power.c --- a/xen/arch/x86/acpi/power.c Tue Jun 26 18:05:22 2007 -0400 +++ b/xen/arch/x86/acpi/power.c Tue Jun 26 19:44:36 2007 -0400 @@ -25,6 +25,7 @@ #include <xen/sched.h> #include <xen/domain.h> #include <xen/console.h> +#include

Xen/MCE: vMCE injection In our test for win8 guest mce, we find a bug that no matter what SRAO/SRAR error xen inject to win8 guest, it always reboot. The root cause is, current Xen vMCE logic inject vMCE# only to vcpu0, this is not correct for Intel MCE (Under Intel arch, h/w generate MCE# to all CPUs). This patch fix vMCE injection bug, injecting vMCE# to all vcpus. Signed-off-by: Liu,

This patch implements cpu offline feature. Best Regards Haitao Shan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Allow one vcpu to pause self, with full context sync-ed. Signed-off-by Kevin Tian <kevin.tian@intel.com> diff -r f6443af464be xen/common/domain.c --- a/xen/common/domain.c Tue Feb 13 13:37:12 2007 +0800 +++ b/xen/common/domain.c Tue Feb 13 13:41:44 2007 +0800 @@ -375,6 +375,18 @@ void vcpu_pause_nosync(struct vcpu *v) vcpu_sleep_nosync(v); } +/* This is not a code path called from

Hi, Is anybody know the purpose of this method (xen_evtchn_do_upcall)? When I run a user level application involved in TCP receiving and the SoftIRQ for eth0 on the same CPU core, everything is OK. But if I run them on 2 different cores, there will be xen_evtchn_do_upcall() existing (maybe when the local_bh_disable<http://www.cs.fsu.edu/~baker/devices/lxr/http/ident?i=local_bh_disable>() or

Stamp softlockup thread earlier before do_timer, because the latter is the one to actually trigger lock warning for long-time offline. Or else, I obserevd softlockup warning easily at manual vcpu hot-remove/plug, or when suspend cancel into old context. One point here is to cover both stolen and blocked time to compare with offline threshold. vcpu hotplug falls into ''stolen''

Patches that were posted last week - with review comments addressed.

I''ve put together two patches. The first introduces a new dom0_op, set_max_vcpus, which with an associated variable and a check in the VCPUOP handler fixes [1]bug 288. Also included is a new VCPUOP, VCPUOP_create, which handles all of the vcpu creation tasks and leaves initialization and unpausing to VCPUOP_initialize. The separation allows for build-time allocation of vcpus which

The patch ''mem_event: use wait queue when ring is full'' I just sent out makes use of the waitqueue feature. There are two issues I get with the change applied: I think I got the logic right, and in my testing vcpu->pause_count drops to zero in p2m_mem_paging_resume(). But for some reason the vcpu does not make progress after the first wakeup. In my debugging there is one

On Wed, Oct 15, 2014 at 01:49:55PM +0000, VONDRA Alain wrote: > If I do kill -9, do I get a core dump ? I'm not sure, but ... > Killall does nothing the process is still alive... > Each time I got this hang, I find only umount -f /tmp/xxxx to force > qemu-img to stop. Are you sure this couldn't be an NFS server problem? Any message or errors in 'dmesg'? Any kernel

On Wed, Oct 15, 2014 at 03:23:39PM +0000, VONDRA Alain wrote: > I see only qemu-img consumming some CPU and MEM : > > 25897 qemu 20 0 5825976 2,429g 4368 S 5,6 32,2 603:09.34 qemu-kvm That's qemu, not qemu-img. > I have indeed, some nfs errors : > > [475747.296041] nfs: server 192.203.100.247 not responding, still trying > [475747.772022] nfs: server

Hello, Have Centos a Repository with corrected or newer Packages for KVM. On my brand new System ;-), but also with my older System. I have big problems with KVM guests "slow slow slow", the DomU's are also CentOS 7 virt-manager is also broken with the 7.1 The "old" Bug in the Kernel is really bad, I have several hundreds log from the vcpu0 Problem. thank's for a

I attempted an upgrade of our production system from Asterisk/Zaptel 1.2 to 1.4 this weekend. Intially everything looked like it was working properly, but some time in the day following the upgrade, the system died to a kernel panic. I wasn't able to catch the entire kernel dump on the console unfortunately. I attempted to isolate the panic, and found that when 'service zaptel stop'

On Mon, Jan 22, 2018 at 10:38 PM, Nathan March <nathan at gt.net> wrote: > Just a heads up that I'm seeing major stability problems on these builds. > Didn't have console capture setup unfortunately, but have seen my test > hypervisor hard lock twice over the weekend. > > This is with xpti being used, rather than the shim. Thanks for the heads-up. It's been

Keir: Not sure from when, at least now hvm_do_resume is double invoked in both 1: arch_vmx_do_resume from schedule_tail, and 2) vmx_asm_do_vmentry of ASM code for both x86 32 & 64 bits. I am wondering if the #1 is a redundant, can u have a double check? thx,eddie _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Hi, As told in "Control Groups Resource Management" libvirt page : Legacy cgroups layout Prior to libvirt 1.0.5, the cgroups layout created by libvirt was different from that described above, and did not allow for administrator customization. Libvirt used a fixed, 3-level hierarchy libvirt/{qemu,lxc}/$VMNAME which was rooted at the point in the hierarchy where libvirtd itself was

I''m just doing some testing on the gplpv drivers with different ways of handling interrupts, and I''m trying a scheme where each xen device (eg vbd/vif) driver attaches to the same IRQ as the pci driver, and each handles it in sequence. In testing though, I noticed the following when logging what each ISR is doing: 60.32381439 - evtchn event on port 5 60.32384109 - port 5

>5. LTP testing might run very slow in SMP VTI Domain with credit scheduler. If binding VTI >and Xen0 vcpu, this bug won''t be there. Hi keir, In credit scheduler, two vcpus in the same domain may be scheduled on the same CPU. For instance, vcpu0 and vcpu1 are running on the same CPU, vcpu0 is doing spin_lock in guest, then time slice is due, vcpu0 is scheduled out before doing

During context switch is_running is set for the next vcpu before the gic state is actually saved. This leads to possible nasty races when interrupts need to be injected after is_running is set to the next vcpu but before the currently running gic state has been saved from the previous vcpu. Use current instead of is_running to check which one is the currently running vcpu: set_current is called

When using the 4.3.0-3/4.3.0-3+b1 xen packages from the Debian archive, things work fine. However, when we compile the xen=4.3.0-3 source package ourselves, we run into an issue launching an HVM. As soon as the HVM bios is loaded, VCPU0 gets a triple fault and the HVM is destroyed (this is with "loglvl=all guest_loglvl=all hvm_debug=3" boot options). (XEN) HVM1: Multiprocessor