similar to: [PATCH] x86/HVM: move per-vendor function tables into .init.data

Also, correct a copy&paste error in the documentation. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> --- This patch has been in the XenServer patch queue for a long time. It is more for debugging purposes than anything else, but is still proving to be valuable for tracking down bugs with HVM paging operations. diff -r 5af4f2ab06f3 -r e6ec5b2b717f

The previous order of relinquish resource is: relinquish_domain_resources() -> vcpu_destroy() -> nvmx_vcpu_destroy(). However some L1 resources like nv_vvmcx and io_bitmaps are free in nvmx_vcpu_destroy(), therefore the relinquish_domain_resources() will not reduce the refcnt of the domain to 0, therefore the latter vcpu release functions will not be called. To fix this issue, we need to

Direct calls perform better, so we should prefer them and use indirect ones only when there indeed is a need for indirection. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/apic.c +++ b/xen/arch/x86/apic.c @@ -1373,7 +1373,7 @@ void error_interrupt(struct cpu_user_reg void pmu_apic_interrupt(struct cpu_user_regs *regs) { ack_APIC_irq(); -

Now that the feature is officially documented (see http://support.amd.com/us/Processor_TechDocs/24593.pdf), I think it makes sense to also allow HVM guests to make use of it. Signed-off-by: Jan Beulich <jbeulich@novell.com> Cc: Andre Przywara <andre.przywara@amd.com> --- 2010-05-04.orig/xen/arch/x86/hvm/hvm.c 2010-04-22 14:43:25.000000000 +0200 +++ 2010-05-04/xen/arch/x86/hvm/hvm.c

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

From 159251a04afcdcd8ca08e9f2bdfae279b2aa5471 Mon Sep 17 00:00:00 2001 From: Liu Jinsong <jinsong.liu@intel.com> Date: Thu, 31 Oct 2013 06:38:15 +0800 Subject: [PATCH 4/4] XSA-60 security hole: flush cache when vmentry back to UC guest This patch flush cache when vmentry back to UC guest, to prevent cache polluted by hypervisor access guest memory during UC mode. The elegant way to do this

SVI should be restored in case guest is processing virtual interrupt while saveing a domain state. Otherwise SVI would be missed when virtual interrupt delivery is enabled. Signed-off-by: Jiongxi Li <jiongxi.li@intel.com> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c index ee2294c..38ff216 100644 --- a/xen/arch/x86/hvm/vlapic.c +++ b/xen/arch/x86/hvm/vlapic.c @@

[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 {

From: Yang Zhang <yang.z.zhang@Intel.com> The follwoing patches are adding the Posted Interrupt supporting to Xen: Posted Interrupt allows vAPIC interrupts to inject into guest directly without any vmexit. - When delivering a interrupt to guest, if target vcpu is running, update Posted-interrupt requests bitmap and send a notification event to the vcpu. Then the vcpu will handle this

The aim of this patch is to define a stable way in which PVH is going to do AP bringup. Since we are running inside of a HVM container, PVH should only need to set flags, cr3 and user_regs in order to bring up a vCPU, the rest can be set once the vCPU is started using the bare metal methods. Additionally, the guest can also set cr0 and cr4, and those values will be appended to the default values

Implement tsc adjust feature IA32_TSC_ADJUST MSR is maintained separately for each logical processor. A logical processor maintains and uses the IA32_TSC_ADJUST MSR as follows: 1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0; 2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or subtracts) value X from the TSC, the logical processor also adds (or subtracts) value X

Otherwise we may leak memory when setting up nHVM fails half way. This implies that the individual destroy functions will have to remain capable (in the VMX case they first need to be made so, following 26486:7648ef657fe7 and 26489:83a3fa9c8434) of being called for a vCPU that the corresponding init function was never run on. Once at it, also remove a redundant check from the corresponding

Hello, I tried to write a piece of code to start vmx. This code is directly interacting with cpu instead of with virtual cpu as in xen. But every time I call vmxon, a GP exception happens. Could anybody help me on this? The following is the context 1. After booting up to the program, I disable A20M. 2. allocate a 4kb-aligned vmxon region and calculate its physical address. 3. setup

Changes from v1: - Define new struct hvm_trap to represent information of trap, include instruction length. - Renames hvm_inject_exception to hvm_inject_trap. Then define a couple of wrappers around that function for existing callers, so that their parameter lists actually *shrink*. This series of patches fix the mistake for debug exception(#DB), overflow exception(#OF) and INT3(#BP),

Why is there an argument returned in the function below (of hvm.h), knowing that there is void? static inline void hvm_init_ap_context(struct vcpu_guest_context *ctxt, int vcpuid, int trampoline_vector) { return hvm_funcs.init_ap_context(ctxt, vcpuid, trampoline_vector); } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Hi all, that''s the situation: machine: IBM x3400 (MT7976) with 2 Xeon E5310 and 4GB of RAM xen version: 4.01 Enterprise problem: Installation CD doesn''t boot, it locks on this error: --------------------------------------------------------------------------- Xen call trace shows codes about: vmx_ini_vmcs_config start_vmx identify_cpu smp_store_cpu_info smp_callin

hvm: clear vmxe if vmxoff The current Xen code keeps X86_CR4_VMXE set even if VMXON has not been executed. The stop_vmx() code assumes that it is possible to call VMXOFF if X86_CR4_VMXE is set which is not always true. Calling VMXOFF without VMXON results in an illegal opcode trap, and to avoid this condition this patch makes sure that X86_CR4_VMXE is only set when VMXON has been called.

(Applies cleanly only on top of the previously sent SVM/LBR patch.) Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2007-08-08/xen/arch/x86/hvm/svm/svm.c =================================================================== --- 2007-08-08.orig/xen/arch/x86/hvm/svm/svm.c 2007-08-08 11:40:11.000000000 +0200 +++ 2007-08-08/xen/arch/x86/hvm/svm/svm.c 2007-08-08 11:43:53.000000000 +0200

From: Zhang Xiantao <xiantao.zhang@intel.com> With virtual EPT support, L1 hyerpvisor can use EPT hardware for L2 guest''s memory virtualization. In this way, L2 guest''s performance can be improved sharply. According to our testing, some benchmarks can show > 5x performance gain. Signed-off-by: Zhang Xiantao <xiantao.zhang@intel.com> Zhang Xiantao (11):

This patch series is a reworking of a series developed by Mukesh Rathor at Oracle. The entirety of the design and development was done by him; I have only reworked, reorganized, and simplified things in a way that I think makes more sense. The vast majority of the credit for this effort therefore goes to him. This version is labelled v13 because it is based on his most recent series, v11.