[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC PATCH 6/16]: PVH xen: Define pvh guest and header changes..



At 17:51 -0800 on 11 Jan (1357926698), Mukesh Rathor wrote:
> diff -r fadb3f2f5d97 -r 5af39353f3f9 xen/include/asm-x86/guest_access.h
> --- a/xen/include/asm-x86/guest_access.h      Fri Jan 11 16:25:27 2013 -0800
> +++ b/xen/include/asm-x86/guest_access.h      Fri Jan 11 16:27:46 2013 -0800
> @@ -14,27 +14,27 @@
>  
>  /* Raw access functions: no type checking. */
>  #define raw_copy_to_guest(dst, src, len)        \
> -    (is_hvm_vcpu(current) ?                     \
> +    (is_hvm_or_pvh_vcpu(current) ?                     \
>       copy_to_user_hvm((dst), (src), (len)) :    \
>       copy_to_user((dst), (src), (len)))
>  #define raw_copy_from_guest(dst, src, len)      \
> -    (is_hvm_vcpu(current) ?                     \
> +    (is_hvm_or_pvh_vcpu(current) ?                     \
>       copy_from_user_hvm((dst), (src), (len)) :  \
>       copy_from_user((dst), (src), (len)))
>  #define raw_clear_guest(dst,  len)              \
> -    (is_hvm_vcpu(current) ?                     \
> +    (is_hvm_or_pvh_vcpu(current) ?                     \
>       clear_user_hvm((dst), (len)) :             \
>       clear_user((dst), (len)))
>  #define __raw_copy_to_guest(dst, src, len)      \
> -    (is_hvm_vcpu(current) ?                     \
> +    (is_hvm_or_pvh_vcpu(current) ?                     \
>       copy_to_user_hvm((dst), (src), (len)) :    \
>       __copy_to_user((dst), (src), (len)))
>  #define __raw_copy_from_guest(dst, src, len)    \
> -    (is_hvm_vcpu(current) ?                     \
> +    (is_hvm_or_pvh_vcpu(current) ?                     \
>       copy_from_user_hvm((dst), (src), (len)) :  \
>       __copy_from_user((dst), (src), (len)))
>  #define __raw_clear_guest(dst,  len)            \
> -    (is_hvm_vcpu(current) ?                     \
> +    (is_hvm_or_pvh_vcpu(current) ?                     \
>       clear_user_hvm((dst), (len)) :             \
>       clear_user((dst), (len)))

Please don't mess up these nicely aligned backslashes. :)

>  
> diff -r fadb3f2f5d97 -r 5af39353f3f9 xen/include/asm-x86/system.h
> --- a/xen/include/asm-x86/system.h    Fri Jan 11 16:25:27 2013 -0800
> +++ b/xen/include/asm-x86/system.h    Fri Jan 11 16:27:46 2013 -0800
> @@ -4,9 +4,15 @@
>  #include <xen/lib.h>
>  #include <asm/bitops.h>
>  
> +/* We need vcpu because during context switch, going from pure PV to PVH,
> + * in save_segments(), current has been updated to next, and no longer 
> pointing
> + * to the pure PV. BTW, for PVH, we update regs->selectors on each vmexit */
>  #define read_segment_register(vcpu, regs, name)                 \
>  ({  u16 __sel;                                                  \
> -    asm volatile ( "movw %%" STR(name) ",%0" : "=r" (__sel) );  \
> +    if (is_pvh_vcpu(v))                                         \
> +        __sel = regs->name;                                     \
> +    else                                                         \
> +        asm volatile ( "movw %%" STR(name) ",%0" : "=r" (__sel) );  \

Or these.  

>      __sel;                                                      \
>  })
>  
> diff -r fadb3f2f5d97 -r 5af39353f3f9 xen/include/asm-x86/x86_64/regs.h
> --- a/xen/include/asm-x86/x86_64/regs.h       Fri Jan 11 16:25:27 2013 -0800
> +++ b/xen/include/asm-x86/x86_64/regs.h       Fri Jan 11 16:27:46 2013 -0800
> @@ -11,9 +11,10 @@
>  #define ring_3(r)    (((r)->cs & 3) == 3)
>  
>  #define guest_kernel_mode(v, r)                                 \
> +   ( is_pvh_vcpu(v) ? ({BUG_ON(v!=current); ring_0(r);}) :  \
>      (!is_pv_32bit_vcpu(v) ?                                     \
>       (ring_3(r) && ((v)->arch.flags & TF_kernel_mode)) :        \
> -     (ring_1(r)))
> +     (ring_1(r))) )

Guess what I'm going to say here. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.