I had sent a mail to that effect (at least I think I had) - on x86-64, this may
be the preferred way (at least for the !XEN_COMPAT case), but the i386
kernel has to remain runnable on 32-bit Xen, and doing gp-fault-recoverable
MSR accesses doesn't buy us anything in terms of not needing specialized
Xen code (i.e. if we need special Xen code, we can equally well do hypercalls).
For that reason, at this point I implemented both access methods, but haven't
got around yet to make the kernel side use them.
Jan
>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 06/23/07 6:22 PM >>>
Thanks. By the way, I've been thinking that rather than rev'ing the
paravirtual hypercall interface for specifying syscall/sysenter callback
points, since these have a direct native equivalent that we're trying to
emulate the semantics of as closely as possible then we may as well emulate
the MSRs for specifying RIP/RFLAGS_mask/etc too. Callers can catch the #GP
to detect whether the new MSR-based interface is supported, and/or we can
add a feature flag in our CPUID leaves.
-- Keir
On 22/6/07 16:01, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
> While this is not really matching native behavior, no guest seems to assume
> EFLAGS.DF being set or reflecting application state. Thus clear it for now,
> the syscall/sysenter patch that I'll hopefully be able to get to work will
> then introduce a more consistent solution. In any case, without this any
> app can easily force kernel data corruption.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>
> Index: 2007-06-18/xen/arch/x86/x86_64/entry.S
> ===================================================================
> --- 2007-06-18.orig/xen/arch/x86/x86_64/entry.S 2007-06-22 16:35:55.000000000
> +0200
> +++ 2007-06-18/xen/arch/x86/x86_64/entry.S 2007-06-22 16:36:59.000000000 +0200
> @@ -34,6 +34,7 @@ switch_to_kernel:
> jnc 1f
> movb $TBF_INTERRUPT,TRAPBOUNCE_flags(%rdx)
> 1: call create_bounce_frame
> + andl $~X86_EFLAGS_DF,UREGS_eflags(%rsp)
> jmp test_all_events
>
> /* %rbx: struct vcpu, interrupts disabled */
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home