similar to: Guest time and TSCs since changeset 17716

The value of ACPI PM-Timer may be broken on save unless the timer mode is delay_for_missed_ticks. With other timer modes, vcpu->arch.hvm_vcpu.guest_time is always zero and the adjustment from its value is wrong. This patch fixes the saved value of ACPI PM-Timer: - don''t adjust the PM-Timer if vcpu->arch.hvm_vcpu.guest_time is zero. - consolidate calculations of PM-Timer to one

Various versions of Linux under various circumstances select TSC as the primary clocksource for the kernel. This is especially true for uniprocessor kernels, but also in some cases for multiprocessor kernels. In most cases, this is because a processor bit (tsc_invariant? constant_tsc?) is passed through directly from the hardware via Xen and tested by the hvm guest and the result implies that

[PATCH 4/8] HVM save restore: vcpu context support Signed-off-by: Zhai Edwin <edwin.zhai@intel.com> save/restore HVM vcpu context such as vmcs diff -r ee20d1905bde xen/arch/x86/domain.c --- a/xen/arch/x86/domain.c Thu Jan 11 16:40:55 2007 +0800 +++ b/xen/arch/x86/domain.c Thu Jan 11 16:46:59 2007 +0800 @@ -573,6 +573,7 @@ int arch_set_info_guest( else {

When using a vtsc, hvm_set_guest_time changes hvm_vcpu.stime_offset, which is used in the vcpu time structure to calculate the tsc_timestamp, so after updating stime_offset we need to propagate the change to vcpu_time in order for the guest to get the right time if using the PV clock. This was not done correctly, since in context_switch update_vcpu_system_time was called before vmx_do_resume,

R-help, I am trying to perform a basic anlaysis of the BreastCancer data from "mlbench" using the svm() function in "e1071". I use the following code library("e1071") library("mlbench") data(BreastCancer) BC <- subset(BreastCancer, select=-Id) pairs(BC) model <- svm(Class ~ ., data=BC, cross=10) ## plot(model, BC, ) tobj <- tune.svm(Class ~ .,

Hi Ian/Stefano: I changed over to the PV clock for hybrid liked we talked at the hackathon. I still have the hang in update_wall_time() after dom0 switches to xen as clocksource. The source of hang seems to be in xen stime_local_stamp in cpu_time that suddenly jumps to a large 64bit value. I''ve been chasing to figure where that happens, and why for the hybrid and not PV. It appears the

Hi all, this small patch series implement guest SMP support for ARM, using the ARM PSCI interface for secondary cpu bringup. Stefano Stabellini (4): xen/arm: basic PSCI support, implement cpu_on xen/arm: support for guest SGI xen/arm: support vcpu_op hypercalls xen: move VCPUOP_register_vcpu_info to common code xen/arch/arm/domain.c | 66 ++++++++++++++++++++++++

Hello all, I'm working with the svm (libsvm) implementation from library(e1071). Currently I'm trying to extend recursive feature elimination (R-SMV) to work with multiclass classification. My problem is that if I run svm for a 3 class problem I get a 2-D vector back from model$coefs, can someone explain me what this values are? I understand them in the 2-class problem where this is a

Hi Everyone I am struggling to get going with support vector machines in R - smv() and predict() etc. Does anyone know of a good tutorial covering R and these things? Stephen [[alternative HTML version deleted]]

The UIP(update in progress) is set when RTC is in updating. And the update cycle begins 244us later after UIP is set. Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com> diff -r 47cb862a07c2 -r edc35b026509 xen/arch/x86/hvm/rtc.c --- a/xen/arch/x86/hvm/rtc.c Mon Mar 05 14:39:07 2012 +0800 +++ b/xen/arch/x86/hvm/rtc.c Mon Mar 05 14:39:41 2012 +0800 @@ -28,6 +28,8 @@ #include

Change from v2: re-written code in ''vmx_intr_assist'' into if()/else if() sequence to make code change easy to review. Virtual interrupt delivery avoids Xen to inject vAPIC interrupts manually, which is fully taken care of by the hardware. This needs some special awareness into existing interrupr injection path: For pending interrupt from vLAPIC, instead of direct injection, we