similar to: [PATCH] Cleanup vmx vmexit handler.

This patch adds CR8 virtualization. It''s the initial patch for booting HVM x64 Windows guest, and just let every CR8 access issues vmexit. And later we will do acceleration to it. Signed-off-by: Xiaohui Xin <xiaohui.xin@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Better use of VMX execution controls MSR. Signed-off-by: Xin Li<xin.b.li@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

The self_nmi() code cause''s an NMI to be triggered by sending an APIC message to the local processor. However, NMIs are blocked by the VMEXIT, until the next iret or VMENTER. Volume 3 Chapter 27 Section 1 of the Intel SDM states: An NMI causes subsequent NMIs to be blocked, but only after the VM exit completes. As a result, as soon as the VMENTER happens, an immediate VMEXIT happens

Hi All, I am trying to provide services to guest VMs where I wish to run guest VMs in a loop. I wish to use a core to schedule a guest VM, service it eg. execute an ISR etc and then return to the context of Xen on that core, so that I can then schedule the next VM on that core. In doing all this, the goal is to avoid the calls to VMEntry and VMExit. Is there a workaround for this to be done or

Add MOVSX instr support to VMX MMIO decoder. Signed-off-by: Xin Li <xin.b.li@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi, Lately I was puzzled by a vmexit reason 31 which was defined as EXIT_REASON_MSR_READ I allocated an array in xen data section and assigned its MFN to an EPT entry of a domainU, I thought the domU could access this array but after that the domainU crashed and xen gave me this exit reason "Bad vmexit (reason 31)" But there is nothing to do with MSR READ, so I''m confused...

Remove the do_nmi() call from the vmexit logic, as the NMI is held pending and will be handled in the context of the host when the STGI instruction is executed. This patch only modifies AMD-V code. This patch is required even without the other Xenoprofile patches applied. Applies cleanly to c/s 11831. Please apply to xen-unstable.hg regardless of the other patches. We also want these patches

hello list: I add some code to xen-3.1.0-src\xen\arch\x86\hvm\vmx\vmx.c to export some information when vmx_vmexit_handler() executed: ------------------------------------------------------------------------------------------------- --- vmx.c 2007-05-18 22:45:22.000000000 +0800 +++ vmx-patch.c 2008-11-24 14:19:18.000000000 +0800 @@ -50,7 +50,9 @@ #include <asm/hvm/vpt.h> #include

I recently realized that the original way of dealing with the DebugCtl MSR on VMX failed to make use of the dedicated guest VMCS field. This is being fixed with this patch. What is puzzling me to a certain degree is that while there is a guest VMCS field for this MSR, there''s no equivalent host load field, but there''s also no indication that the MSR would be cleared during a

This patch implements a new mechanism to buffer the MMIO_WRITE and PIO_WRITE packet in a queue, and then submit them to qemu-dm in batch. This could save a lot of domain switch time. We implement this as a generic one to do ioreq in batch. However, we only use it to batch the MMIO_WIRTE request for stdvga(0xA0000-0xC0000) in order to solve the win2k boot issue for hvm domain. Without this patch,

Fix virtual apic irq distribution. But currently we inject PIT irqs to cpu0 only. Also mute some warning messages. Signed-off-by: Yunhong Jiang <yunhong.jiang@intel.com> Signed-off-by: Xin Li <xin.b.li@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

This patch enables tracing VMEXIT/ENTRY for 64-bit systems (are there any 32-bit VT enabled systems out there?) Signed-off by Himanshu Raj (rhim.list@nosuchaddr.com) -- ------------------------------------------------------------------------- Himanshu Raj PhD Student, GaTech (www.cc.gatech.edu/~rhim) I prefer to receive attachments in an open, non-proprietary format.

From: Yang Zhang <yang.z.zhang@Intel.com> The following patches fix the issue that fail to boot L2 guest on APIC-v available machine. The main problem is that with APIC-v, virtual interrupt inject L1 is totally through APIC-v. But if virtual interrupt is arrived when L2 is running, L1 will detect interrupt through vmexit with reason external interrupt. If this happens, we should update

From: Yang Zhang <yang.z.zhang@Intel.com> With virtual unrestricted guest feature, L2 guest is allowed to run with PG cleared. Also, allow PAE not set during virtual vmexit emulation. Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com> --- xen/arch/x86/hvm/hvm.c | 3 ++- xen/arch/x86/hvm/vmx/vvmx.c | 3 +++ 2 files changed, 5 insertions(+), 1 deletions(-) diff --git

On 25/09/2017 06:44, Wei Wang wrote: > > +static void update_msr_autoload_count_max(void) > +{ > + u64 vmx_msr; > + int n; > + > + /* > + * According to the Intel SDM, if Bits 27:25 of MSR_IA32_VMX_MISC is > + * n, then (n + 1) * 512 is the recommended max number of MSRs to be > + * included in the VMExit and VMEntry MSR auto switch list. > + */ > +

On 25/09/2017 06:44, Wei Wang wrote: > > +static void update_msr_autoload_count_max(void) > +{ > + u64 vmx_msr; > + int n; > + > + /* > + * According to the Intel SDM, if Bits 27:25 of MSR_IA32_VMX_MISC is > + * n, then (n + 1) * 512 is the recommended max number of MSRs to be > + * included in the VMExit and VMEntry MSR auto switch list. > + */ > +

[VMX] Add support for Pause-Loop Exiting New NHM processors will support Pause-Loop Exiting by adding 2 VM-execution control fields: PLE_Gap - upper bound on the amount of time between two successive executions of PAUSE in a loop. PLE_Window - upper bound on the amount of time a guest is allowed to execute in a PAUSE loop If the time, between this execution of PAUSE

>Since this happens early in HVM guest boot, I suggest adding tracing to >vmx_vmexit_handler() to dump registers on every MSR write. >Something like >this early on in the function: > if ( reason == EXIT_REASON_MSR_WRITE ) { > printk("regs==%p, guest_regs==%p\n", &regs, >guest_cpu_user_regs()); > show_registers(&regs); > } > >This will

The patch enables x86_32 PAE unmodified guests on 64-bit Xen when the hvm feature is present. We tested only Linux at this point, and we''ll improve the functionality as we test other guests. The SVM needs the equivalent changes to the vmc.c to get this functionality working, but this patch does not break the build. Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>

Is there any particular reason why on 32-bits the order is VMLOAD then HVM_SAVE_ALL_NOSEGREGS, while on 64-bits its is the other way around? Trying to put in the saving of EAX, I could save a GET_CURRENT() on 32-bits if I could order things the same way as on 64-bits. Also, both versions seem to have a redundant GET_CURRENT() right after the clgi/sti sequence - again, is there a particular reason