search for: vmx_intr_assist

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

..._step to support pre-MTF systems, in a way that would mimic the MTF? So far I''m emulating PUSHF/POPF to hide the hypervisor''s trap flag, and eventually I''ll multiplex it down to the guest, but I''m having issues. Right now, I''m enabling X86_EFLAGS_TF in vmx_intr_assist, just like where MTF is enabled if desired. It''s cleared at the start of vmx_exit_handler (if required). I''m catching single step from TRAP_debug, but when I disable stepping the guest usually seems to hang. It''s not completely frozen, because if I turn single stepping ba...

If HVM guest Fedora 7 uses PIT and lapic timer, it can''t boot or install. The cause is: At some point, Fedora 7 disables PIT interrupt by "vioapic.redirtbl[2].mask = 1, vpic.imr.bit0 = 0 (unmasked), vlapic.lvt[LINT0].mask = 1", and enables vlapic timer interrupt generating; In vmx_intr_assist() -> pt_update_irq(), we always choose IRQ0 rather than vlapic timer interrupt, because: 1) is_isa_irq_masked(v, 0) returns false due to vpic.imr.bit0 = 0; 2) the PIT''s pt->last_plt_gtime is less than vlapic timer''s -- at least I can see this on my hosts; However, in pt_upd...

...vlapic_find_highest_isr(s), v); + vlapic_adjust_i8259_target(d); lapic_rearm(s); return 0; diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c index c5c503e..8306237 100644 --- a/xen/arch/x86/hvm/vmx/intr.c +++ b/xen/arch/x86/hvm/vmx/intr.c @@ -290,8 +290,8 @@ void vmx_intr_assist(void) vmx_set_eoi_exit_bitmap(v, pt_vector); /* we need update the RVI field */ - status &= ~(unsigned long)0x0FF; - status |= (unsigned long)0x0FF & + status &= ~(unsigned long)VMX_GUEST_INTR_STATUS_SUBFIELD_BITMASK; + status |= (uns...

Currently, Xen does not support injecting an NMI to HVM guest OS. Adding this feature is necessary for those softwares which depend on NMI to function correctly, such as KDB and oprofile. The attached patch allows NMI to be injected to guest OS in NMIP capable platforms. It also enables to queue an NMI and then inject it as soon as possible. Signed-off-by: Haitao Shan

....c | 43 +++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 44 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c index 535248a..c5c503e 100644 --- a/xen/arch/x86/hvm/vmx/intr.c +++ b/xen/arch/x86/hvm/vmx/intr.c @@ -324,7 +324,9 @@ void vmx_intr_assist(void) } out: - if ( !cpu_has_vmx_virtual_intr_delivery && cpu_has_vmx_tpr_shadow ) + if ( !nestedhvm_vcpu_in_guestmode(v) && + !cpu_has_vmx_virtual_intr_delivery && + cpu_has_vmx_tpr_shadow ) __vmwrite(TPR_THRESHOLD, tpr_threshold); }...

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

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

Hello, This series has been split into two patches, one for arm and one for x86. I figured that this was easier than doing it as a single combined patch, especially as the changes are functionally independent. x86 has been boot tested, but arm has not even been compile tested as I lack a suitable cross compiler. However, the changes are just text replacement, so I dont expect any issues. The

I''m looking into getting Xenoprof to tun in an HVM domain, since we will eventually need a profiler for HVM domains to track down areas of poor performance. (HVMs have poor performance? :) ) Being relatively new to OProfile, Xenoprof, and Xen internals, I would appreciate any pointers, tips, and comments on how to work the implementation. I see three basic areas of work. 1. Implement

We (Michael Fetterman, George Dunlap and I) have been working over the last while on a full replacement for Xen''s shadow pagetable support. This mail contains some design notes, below; a patch against xen-unstable, giving a snapshot of the current state of the new shadow code, is at http://www.cl.cam.ac.uk/~tjd21/shadow2.patch Comments on both are welcome, although the code is not

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),

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.