search for: tf_kernel_mod

...(guest_kernel_mode(current, regs))                 mode = 1;         else if (ring_0(regs))                 mode = 2; If I look at the definition for guest_kernel_mode() it is: include/asm-x86/x86_64/regs.h: #define guest_kernel_mode(v, r)   \     (ring_3(r) && ((v)->arch.flags & TF_kernel_mode)) (Note well:  I am running a 64 bit guest and a 64 bit host.) So, how is that possibly true for the kernel in an HVM guest? (Wouldn''t guest_kernel_mode(regs) be false in that case since it is not running ring_3()?) Also, wouldn''t ring_0(regs) be true if we are running in ker...

...c(kernel_ss) || c(kernel_sp) || c.nat->gs_base_kernel || c.nat->gdt_ents || c.nat->fs_base || c.nat->gs_base_user ) return -EINVAL; } @@ -745,17 +750,20 @@ int arch_set_info_guest( if ( has_hvm_container_vcpu(v) ) { - /* - * NB: TF_kernel_mode is set unconditionally for HVM guests, - * 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...

Hi, I implemented my own Hypercall in xen. Now I wish my application under dom0 could talk to Xen via my hypercall. Currently, I make a stub in dom0''s kernel, which works as a proxy to forward the request. So, my application first makes a system call to dom0, which then makes hypercall to xen. Is this design necessary? May I call hypercalls from user application under dom0 directly?

...if ( cpu_has_rdtscp @@ -3436,6 +3463,8 @@ v->domain->vcpu[0]->arch.hvm_vcpu.cache_tsc_offset; hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset); + v->arch.hvm_vcpu.msr_tsc_adjust = 0; + paging_update_paging_modes(v); v->arch.flags |= TF_kernel_mode; diff -r d5c677159abb xen/include/asm-x86/hvm/vcpu.h --- a/xen/include/asm-x86/hvm/vcpu.h Thu Sep 20 21:50:56 2012 +0800 +++ b/xen/include/asm-x86/hvm/vcpu.h Thu Sep 20 23:34:04 2012 +0800 @@ -137,6 +137,7 @@ struct hvm_vcpu_asid n1asid; u32 msr_tsc_aux; + u64...

...guests. It may need to be >fixed -- it had previously only been used in paravirtual-only contexts. > >It might make sense to invert[*] the predicate and rename to >user_mode(). Then definition is simply ring_3(regs) for x86/32 and >(ring_3(regs) && !((v)->arch.flags & TF_kernel_mode)) for x86/64. > >So maybe: > int mode = 2; > if (guest_mode(regs)) > mode = user_mode(current, regs) ? 0 : 1; Yes, this is a better solution for sure, to take both para-domain and hvm into account. But it''s not a problem for now:) _mode_ logic only applies to act...

...3; + v->arch.syscall_eflags_mask = X86_EFLAGS_DF|X86_EFLAGS_TF|X86_EFLAGS_NT| + X86_EFLAGS_RF|X86_EFLAGS_VM; +#endif + return (is_pv_32on64_vcpu(v) ? setup_compat_l4(v) : 0); } @@ -625,7 +631,18 @@ int arch_set_info_guest( v->arch.flags |= TF_kernel_mode; if ( !compat ) + { memcpy(&v->arch.guest_context, c.nat, sizeof(*c.nat)); +#ifdef __x86_64__ + /* + * Despite not being correct, be backwards compatible - most + * importantly in order to prevent the guest from being crashed + * due to use...

1: correct LDT checks 2: add address validity check to guest_map_l1e() 3: use {rd,wr}{fs,gs}base when available 4: check for canonical address before doing page walks Signed-off-by: Jan Beulich <jbeulich@suse.com>

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.