search for: hvm_vcpu

...+++ b/xen/arch/x86/hvm/hvm.c Thu Sep 20 23:34:04 2012 +0800 @@ -244,6 +244,7 @@ void hvm_set_guest_tsc(struct vcpu *v, u64 guest_tsc) { uint64_t tsc; + uint64_t delta_tsc; if ( v->domain->arch.vtsc ) { @@ -255,10 +256,23 @@ rdtscll(tsc); } - v->arch.hvm_vcpu.cache_tsc_offset = guest_tsc - tsc; + delta_tsc = guest_tsc - tsc; + + v->arch.hvm_vcpu.msr_tsc_adjust += delta_tsc + - v->arch.hvm_vcpu.cache_tsc_offset; + v->arch.hvm_vcpu.cache_tsc_offset = delta_tsc; + hvm_funcs.set_tsc_offset(v, v->arch.hvm_vc...

When using a vtsc, hvm_set_guest_time changes hvm_vcpu.stime_offset, which is used in the vcpu time structure to calculate the tsc_timestamp, so after updating stime_offset we need to propagate the change to vcpu_time in order for the guest to get the right time if using the PV clock. This was not done correctly, since in context_switch update_vcpu_sy...

..."while CR4.PCIDE=1"); + goto gpf; + } + /* When CR0.PG is cleared, LMA is cleared immediately. */ if ( hvm_long_mode_enabled(v) ) { @@ -1663,12 +1670,26 @@ int hvm_set_cr4(unsigned long value) } old_cr = v->arch.hvm_vcpu.guest_cr[4]; + + if ( (value & X86_CR4_PCIDE) && !(old_cr & X86_CR4_PCIDE) && + (!hvm_long_mode_enabled(v) || (v->arch.hvm_vcpu.guest_cr[3] & 0xfff)) ) + { + HVM_DBG_LOG(DBG_LEVEL_1, "Guest attempts to change CR4.PCIDE from " +...

Hi all, Does anyone have thoughts on extending v->arch.hvm_vcpu.single_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...

The value of ACPI PM-Timer may be broken on save unless the timer mode is delay_for_missed_ticks. With other timer modes, vcpu->arch.hvm_vcpu.guest_time is always zero and the adjustment from its value is wrong. This patch fixes the saved value of ACPI PM-Timer: - don''t adjust the PM-Timer if vcpu->arch.hvm_vcpu.guest_time is zero. - consolidate calculations of PM-Timer to one function. more precise on save. Signed-off-by:...

...3 +++ 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 7203184..481cb71 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -1732,7 +1732,8 @@ int hvm_set_cr0(unsigned long value) { if ( v->arch.hvm_vcpu.guest_efer & EFER_LME ) { - if ( !(v->arch.hvm_vcpu.guest_cr[4] & X86_CR4_PAE) ) + if ( !(v->arch.hvm_vcpu.guest_cr[4] & X86_CR4_PAE) && + !nestedhvm_vmswitch_in_progress(v) ) { HVM_DBG_LOG(DBG_LE...

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

Hi Keir, csched_load_balance is used to see if there are higher privileged vcpu in other physical processors'' runnable queue, if there is, then migrate this vcpu to this physical processor. But at following scenario, this vcpu migration is unnecessary. 1. idle_vcpu0 is running on lp0, hvm_vcpu is in lp0''s runnable queue, this happens when hvm_vcpu is just being woken up, 2. idle_vcpu1 is running on lp1, there are no vcpu in lp1''s runnable queue, idle_vcpu1 calls scheduler to try to find vcpu in other physical processor to run on lp1, it then finds hvm_vcpu, an...

If a guest sets a state and dirties the state, but later temporarily clears the state, and at this time if this vcpu is scheduled out, then other vcpus may corrupt the state before the vcpu is scheduled in again, thus the state cannot be restored correctly. To solve this issue, this patch save/restore all states unconditionally on vcpu context switch. Signed-off-by: Weidong Han

Hi Ian/Stefano: I changed over to the PV clock for hybrid liked we talked at the hackathon. I still have the hang in update_wall_time() after dom0 switches to xen as clocksource. The source of hang seems to be in xen stime_local_stamp in cpu_time that suddenly jumps to a large 64bit value. I''ve been chasing to figure where that happens, and why for the hybrid and not PV. It appears the

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list

...movw %%ax ,%%" STR(name) "" : : "a" (value) ) +static void svm_update_guest_efer(struct vcpu *); + static struct hvm_function_table svm_function_table; /* va of hardware host save area */ @@ -269,9 +271,9 @@ static int svm_vmcb_restore(struct vcpu v->arch.hvm_vcpu.guest_cr[2] = c->cr2; v->arch.hvm_vcpu.guest_cr[3] = c->cr3; v->arch.hvm_vcpu.guest_cr[4] = c->cr4; - hvm_update_guest_cr(v, 0); - hvm_update_guest_cr(v, 2); - hvm_update_guest_cr(v, 4); + svm_update_guest_cr(v, 0); + svm_update_guest_cr(v, 2); + svm_updat...

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.

...- * so we always use the gs_base_kernel here. If we change this - * function to imitate the PV functionality, we'll need to - * make it pay attention to the kernel bit. - */ - hvm_set_info_guest(v, compat ? 0 : c.nat->gs_base_kernel); if ( is_hvm_vcpu(v) || v->is_initialised ) goto out; + if ( c.nat->ctrlreg[0] ) { + v->arch.hvm_vcpu.guest_cr[0] |= c.nat->ctrlreg[0]; + hvm_update_guest_cr(v, 0); + } + + if ( c.nat->ctrlreg[4] ) { + v->arch.hvm_vcpu.guest_cr[4]...

This series of patches fix the mistake for debug exception(#DB), overflow exception(#OF) and INT3(#BP), INTn instruction emulation. Introduce new function vmx_inject_sw_exception() which deliver the software excetion, software interrupt and privileged software exception. Split hardware exception as a seperate function(old function vmx_inject_hw_exception()). Also Passed down intruction length

...vm.c Mon Sep 10 16:48:15 2012 -0400 @@ -1758,6 +1758,7 @@ int hvm_set_cr3(unsigned long value) { struct vcpu *v = current; struct page_info *page; + unsigned long old; if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) && (value != v->arch.hvm_vcpu.guest_cr[3]) ) @@ -1775,8 +1776,10 @@ int hvm_set_cr3(unsigned long value) HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR3 value = %lx", value); } + old=v->arch.hvm_vcpu.guest_cr[3]; v->arch.hvm_vcpu.guest_cr[3] = value; paging_update_cr3(v); + hvm_memory_eve...

Running a heavily modified xen-unstable changset 19590:f80cf52a4fb6 with debugger_attached set, I was seeing the debug traps getting lost from the EXCEPTION_BITMAP in vmx_update_guest_cr() when transitioning from real to protected mode. In my codebase, I could fix this trivially by clearing the debug_state_latch and letting vmx_do_resume() reapply the setting. However, while it looks like a valid

...t;arch.p2m); return 0; } 3) fix the vmx_load_pdptrs() function in vmx.c in this situation the page directory table is paged out. Although using mdelay() is a bad idea, it''s better than making the xen crash void vmx_load_pdptrs(struct vcpu *v) { unsigned long cr3 = v->arch.hvm_vcpu.guest_cr[3], mfn; uint64_t *guest_pdptrs; p2m_type_t p2mt; char *p; unsigned int try_count = 0; /* EPT needs to load PDPTRS into VMCS for PAE. */ if ( !hvm_pae_enabled(v) || (v->arch.hvm_vcpu.guest_efer & EFER_LMA) ) return; if ( cr3 & 0x1fUL )...

patch revision history ---------------------- v1: Initial patch to handle this issue involving changing the hypercall interface v2:Totally handled inside hypervisor. v3:Change some logics of handling msi-x pending unmask operations. v4:Some changes related to coding style according to Andrew Cooper''s comments v5:Some changes according to Jan''s comments, including a) remove

Hi, Keir, The following patches refines Xen support for CPU Xsave/Xrestore support. There are four patches included. Patch 1/4: Cleaning up existing Xsave code in Xen. Replace xfeature_low and xfeature_high with a u64 variable xfeature_mask. In structure hvm_vcpu, rename xfeature_mask to xcr0 Provide EDX:EAX with all bits set to 1 for XSAVE and XRSTOR as spec recommends Patch 2/4: Adding Xsave/Xrestore support for PV guests. Feature is exposed via CPUID. XSETBV is trapped and emulated by Xen (via GP#). Patch 3/4: Expose AVX to guest OSs. Patch...