similar to: [Patch 0/2] bug fixes for APICV

The "APIC-register virtualization" and "virtual-interrupt deliver" VM-execution control has no effect on the behavior of RDMSR/WRMSR if the "virtualize x2APIC mode" VM-execution control is 0. When guest uses x2APIC mode, we should enable "virtualize x2APIC mode" for APICV first. Signed-off-by: Jiongxi Li <jiongxi.li@intel.com> diff --git

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 @@

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

X86: implement PCID/INVPCID for hvm This patch handle PCID/INVPCID for hvm: For hap hvm, we enable PCID/INVPCID, since no need to intercept INVPCID, and we just set INVPCID non-root behavior as running natively; For shadow hvm, we disable PCID/INVPCID, otherwise we need to emulate INVPCID at vmm by setting INVPCID non-root behavior as vmexit. Signed-off-by: Liu, Jinsong

This issue I am encountering seems to only happen on multi-socket machines. It also does not help that the only multi-socket box I have is an Romley-EP (so two socket SandyBridge CPUs). The other SandyBridge boxes I''ve (one socket) are not showing this. Granted they are also a different model (42). The problem is that when I run ''perf top'' within an SMP PVHVM guest,

Changes from v1 to v2: - Use a macro to replace the hardcode in patch 1/3. This patchset fixes issues about IA32_VMX_MISC MSR emulation, VMCS guest area synchronization about PAGE_FAULT_ERROR_CODE_MASK/PAGE_FAULT_ERROR_CODE_MATCH, and CR0/CR4 emulation. Please help to review and pull. Thanks, Dongxiao Dongxiao Xu (3): nested vmx: emulate IA32_VMX_MISC MSR nested vmx: synchronize page

This patch masks PIC and IOAPIC RTE''s before x2APIC enabling, unmask and restore them after x2APIC enabling. It also really enables interrupt remapping before x2APIC enabling instead of just checking interrupt remapping setting. This patch also handles all x2APIC configuration including BIOS settings and command line settings. Especially, it handles that BIOS hands over in x2APIC mode

Not sure I did the xen log correctly. I have this in /etc/default/grub now: GRUB_CMDLINE_XEN_DEFAULT="loglvl=all" And now here is xen dmesg: root at xen-3:~# xl dmesg (XEN) Xen version 4.3.0 (Debian 4.3.0-3+b1) (buildd-binet at buildd.debian.org) (gcc (Debian 4.8.2-8) 4.8.2) debug=n Wed Dec 4 07:43:54 UTC 2013 (XEN) Bootloader: GRUB 2.00-22 (XEN) Command line: placeholder

Changes from v2 to v3: - Use pfn_to_paddr() to get the address from frame number instead of doing shift directly. - Remove some unnecessary initialization code and add "static" to vmentry_fields and gpdptr_fields. - Enable the VMREAD/VMWRITE bitmap only if nested hvm is enabled. - Use clear_page() to set all 0 to the page instead of memset(). - Use domheap to allocate the

(copying xen-devel, full logs are at bugs.debian.org/748052, this is Debian Jessie, Xen 4.3.0 and Linux 3.13 Mike also reported that Debian Wheezy Xen 4.1.4 didn't work either, not clear which kernel that was with though, Wheezy's 3.2 or Jessie's 3.13) On Thu, 2014-05-15 at 10:11 -0700, Mike Egglestone wrote: > Here are some results with (now) the latest BIOS version 41. (was >

Split VMCS initialization function into guest/host/control 3 parts. 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

On 05/16/2014 06:08 AM, Jan Beulich wrote: >>>> On 16.05.14 at 10:58, <ijc at hellion.org.uk> wrote: >> So it seems like dom0 is unable to (correctly) bind to some hardware >> interrupts. I wonder if these messages from Xen's dmesg are relevant. >> (XEN) Not enabling x2APIC: depends on iommu_supports_eim. >> (XEN) I/O virtualisation disabled >>

vmwrite higher 32 bits of 64bit VMCS fields when in PAE mode. 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

From 291adaf4ad6174c5641a7239c1801373e92e9975 Mon Sep 17 00:00:00 2001 From: Liu Jinsong <jinsong.liu@intel.com> Date: Thu, 28 Nov 2013 05:26:06 +0800 Subject: [PATCH v4 3/7] X86: MPX IA32_BNDCFGS msr handle When MPX supported, a new guest-state field for IA32_BNDCFGS is added to the VMCS. In addition, two new controls are added: - a VM-exit control called "clear BNDCFGS" - a

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

>>> On 16.05.14 at 10:58, <ijc at hellion.org.uk> wrote: > So it seems like dom0 is unable to (correctly) bind to some hardware > interrupts. I wonder if these messages from Xen's dmesg are relevant. > (XEN) Not enabling x2APIC: depends on iommu_supports_eim. > (XEN) I/O virtualisation disabled > (XEN) Enabled directed EOI with ioapic_ack_old on! The last one

On 16/05/14 11:08, Jan Beulich wrote: >>>> On 16.05.14 at 10:58, <ijc at hellion.org.uk> wrote: >> So it seems like dom0 is unable to (correctly) bind to some hardware >> interrupts. I wonder if these messages from Xen's dmesg are relevant. >> (XEN) Not enabling x2APIC: depends on iommu_supports_eim. >> (XEN) I/O virtualisation disabled >> (XEN)

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

[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

Hello Paul I have a GTX 480 (GF100 I believe) at home in an old machine. Is the rest of the Fermi patch set available somewhere for me to test? Thank you Regards Brock On 16 Jan. 2018 9:08 am, "Lyude Paul" <lyude at redhat.com> wrote: It's here! After a lot of investigation, rewrites, and traces, I present the patch series to implement all known )levels of clockgating for