Displaying 8 results from an estimated 8 matches for "guest_kernel_mode".
Did you mean:
get_kernel_mode
2006 Jul 05
4
xenoprof passive profiling and "mode" setting
Xiaowei,
I''m puzzled by the following bit of code in p4_check_ctrs():
if (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))
(...
2006 Jul 06
0
Fwd: RE: xenoprof passive profiling and "mode" setting
...sive profiling and "mode" setting
Date: Wednesday 05 July 2006 21:53
From: "Yang, Xiaowei" <xiaowei.yang@intel.com>
To: "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk>, "Ray Bryant"
<raybry@mpdtxmail.amd.com>
Cc: xen-devel@lists.xensource.com
>guest_kernel_mode() does not work for HVM 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) && !((...
2017 May 04
4
Xen package security updates for jessie 4.4, XSA-213, XSA-214
...++enum mc_disposition {
++ mc_continue,
++ mc_exit,
++ mc_preempt,
++};
++
++#define multicall_ret(call) \
++ (unlikely((call)->op == __HYPERVISOR_iret) \
++ ? mc_exit \
++ : likely(guest_kernel_mode(current, \
++ guest_cpu_user_regs())) \
++ ? mc_continue : mc_preempt)
++
+ #define do_multicall_call(_call) \
+- do { \
++ ({...
2017 May 04
3
Bug#861660: Xen package security updates for jessie 4.4, XSA-213, XSA-214
Moritz Muehlenhoff writes ("Re: Xen package security updates for jessie 4.4, XSA-213, XSA-214"):
> On Thu, May 04, 2017 at 05:06:07PM +0100, Ian Jackson wrote:
> > I have fixed these in stretch but the jessie package remains unfixed.
> > I think I may be able to find some backports somewhere. Would that be
> > useful ? Is anyone else working on this ?
>
>
2008 Feb 01
4
[PATCH] x86: adjust reserved bit page fault handling
One could even debate whether reserved bit faults are always fatal (and
should never be propagated to the guest)...
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Index: 2008-01-28/xen/arch/x86/traps.c
===================================================================
--- 2008-01-28.orig/xen/arch/x86/traps.c 2008-01-28 11:31:44.000000000 +0100
+++ 2008-01-28/xen/arch/x86/traps.c
2013 Oct 10
10
[PATCH 0/4] x86: XSA-67 follow-up
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>
2013 Sep 23
57
[PATCH RFC v13 00/20] Introduce PVH domU support
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.
2013 Jun 04
12
[PATCH 0/4] XSA-52..54 follow-up
The first patch really isn''t as much of a follow-up than what triggered
the security issues to be noticed in the first place.
1: x86: preserve FPU selectors for 32-bit guest code
2: x86: fix XCR0 handling
3: x86/xsave: adjust state management
4: x86/fxsave: bring in line with recent xsave adjustments
The first two I would see as candidates for 4.3 (as well as
subsequent backporting,