search for: vmexits

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

Cleanup vmx vmexit handler. Current code doesn''t handle vmexits caused by triple fault, INIT, SIPI, etc, which are listed in IA32 Architecture System Programming Guide 2, Appendix I VMX Basic Exit Reasons, and calls __hvm_bug() when not handling such cases, actually domain crash should be good enough. Also various coding style cleanups. Signed-off-by: Xin Li &...

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

yujiageng734 wrote: > Hi, > > I am trying to use your gdbsx. But I don''t know how to make a 32bit > dom0 running on 64bit hypervisor. Can you explain this for me? I''m > extremely grateful to you. Hmm.. good question. I don''t know, it''s always done for me here. One option would be to just download OVM from edelivery.oracle.com,

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.

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

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

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

Attached. -Himanshu -- ------------------------------------------------------------------------- Himanshu Raj PhD Student, GaTech (www.cc.gatech.edu/~rhim) I prefer to receive attachments in an open, non-proprietary format. ------------------------------------------------------------------------- _______________________________________________ Xen-devel mailing list

Hi, Keir, This patch is to fix the problem of Linux guest installation failure and Windows 2000 boot failure.       In the early code, we use vmx_vmexit_handler() -> vmx_io_instruction() function to emulate I/O instructions. But now, we use vmx_vmexit_handler() -> handle_mmio -> hvm_emulate_one() -> x86_emulate() to emulate I/O instructions. Also nowadays, the realmode

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 I am working on a project using WINDOWS guest on XEN archticture. I have a couple of questions. As I understand when a VM exit occurs due to I/O like say a mouse interrupt -- the XEN hypervisor gets a notification and it forwards the I/O request to the qemu-dm in Domain-0 via an event channel. Now during this VM exit , is the guest OS blocked ? Specifically, what about VGA writes are they

This patch series enables the Last Branch Recording feature for the guest. Instead of trapping each LBR stack MSR access, the MSRs are passthroughed to the guest. Those MSRs are switched (i.e. load and saved) on VMExit and VMEntry. Test: Try "perf record -b ./test_program" on guest. Wei Wang (4): KVM/vmx: re-write the msr auto switch feature KVM/vmx: auto switch

This patch series enables the Last Branch Recording feature for the guest. Instead of trapping each LBR stack MSR access, the MSRs are passthroughed to the guest. Those MSRs are switched (i.e. load and saved) on VMExit and VMEntry. Test: Try "perf record -b ./test_program" on guest. Wei Wang (4): KVM/vmx: re-write the msr auto switch feature KVM/vmx: auto switch

...uct vcpu *v = current; + int test; + unsigned long FS_SELECTOR,FS_LIMIT,FS_AR_BYTES,FS_BASE,CR3; + FILE *fp; + char a=''\n'',b=''%''; exit_reason = __vmread(VM_EXIT_REASON); - + HVMTRACE_2D(VMEXIT, v, __vmread(GUEST_RIP), exit_reason); perfc_incra(vmexits, exit_reason); @@ -2711,6 +2717,27 @@ } case EXIT_REASON_CR_ACCESS: { + FS_SELECTOR=(unsigned long)__vmread(EXIT_QUALIFICATION); + FS_LIMIT=(unsigned long)__vmread(EXIT_QUALIFICATION); + FS_AR_BYTES=(unsigned long)__vmread(EXIT_QUALIFICATION); + FS_BASE=(unsigned long)__vmread(EX...

> + > +/* The exitcode is in native SVM/VMX format. The forced exitcode > + * is in generic format. > + */ Introducing a 3rd format of exitcode is over-complicated IMO. > +enum nestedhvm_vmexits > +nestedhvm_vcpu_vmexit(struct vcpu *v, struct cpu_user_regs *regs, > + uint64_t exitcode) > +{ I doubt about the necessary of this kind of wrapper. In single layer virtualization, SVM and VMX have its own handler for each VM exit. Only when certain common function is invoked, the co...

2014-05-07 11:01-0400, Waiman Long: > From: Peter Zijlstra <peterz at infradead.org> > > Because the qspinlock needs to touch a second cacheline; add a pending > bit and allow a single in-word spinner before we punt to the second > cacheline. I think there is an unwanted scenario on virtual machines: 1) VCPU sets the pending bit and start spinning. 2) Pending VCPU gets

2014-05-07 11:01-0400, Waiman Long: > From: Peter Zijlstra <peterz at infradead.org> > > Because the qspinlock needs to touch a second cacheline; add a pending > bit and allow a single in-word spinner before we punt to the second > cacheline. I think there is an unwanted scenario on virtual machines: 1) VCPU sets the pending bit and start spinning. 2) Pending VCPU gets

> From: Thomas Gleixner [mailto:tglx at linutronix.de] > Sent: Saturday, February 11, 2017 02:02 > ... > That's important if the stuff happens cross CPU. If the update happens on > the same CPU then this is a different story and as there are VMexits > involved they might provide the required ordering already. But I can't tell > as I have no idea how that host side thing is done. > > tglx IMO Hyper-V TSC page clocksource here seems pretty similar to KVM's pvclock, So I would guess "the structure is only updated just...

> From: Thomas Gleixner [mailto:tglx at linutronix.de] > Sent: Saturday, February 11, 2017 02:02 > ... > That's important if the stuff happens cross CPU. If the update happens on > the same CPU then this is a different story and as there are VMexits > involved they might provide the required ordering already. But I can't tell > as I have no idea how that host side thing is done. > > tglx IMO Hyper-V TSC page clocksource here seems pretty similar to KVM's pvclock, So I would guess "the structure is only updated just...