Re: [Xen-devel] [PATCH v2 1/4] x86/compat: Test whether guest has 32b shinfo instead of being a PV 32b domain

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.06.15 at 22:21, <boris.ostrovsky@xxxxxxxxxx> wrote:
> In preparation for enabling 32-bit PVH guests replace a number of guest mode's
> tests that assume a PV guest with has_32bit_shinfo() that can be applicable 
> to
> both PV and PVH guests.

Apart from this apparently needing re-basing, I also think this should
be swapped with patch 2, as right now it doesn't make much sense to
distinguish the two checks.

> @@ -737,7 +737,7 @@ int arch_set_info_guest(
>  
>      /* The context is a compat-mode one if the target domain is compat-mode;
>       * we expect the tools to DTRT even in compat-mode callers. */
> -    compat = is_pv_32on64_domain(d);
> +    compat = has_32bit_shinfo(d);

Furthermore, looking at uses like this, tying such decisions to the
shared info layout looks kind of odd. I think for documentation
purposes we may need a differently named alias.

> @@ -1721,9 +1721,7 @@ unsigned long hypercall_create_continuation(
>          else
>              curr->arch.hvm_vcpu.hcall_preempted = 1;
>  
> -        if ( is_pv_vcpu(curr) ?
> -             !is_pv_32bit_vcpu(curr) :
> -             curr->arch.hvm_vcpu.hcall_64bit )
> +        if ( !has_32bit_shinfo(curr->domain) )

This is not a valid replacement - hcall_64bit depends on the mode
the vCPU currently is in, while has_32bit_shinfo() doesn't.

> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -496,7 +496,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
> u_domctl)
>              break;
>  
>  #ifdef CONFIG_COMPAT
> -        if ( !is_pv_32on64_domain(d) )
> +        if ( !has_32bit_shinfo(d) )
>              ret = copy_from_guest(c.nat, op->u.vcpucontext.ctxt, 1);
>          else
>              ret = copy_from_guest(c.cmp,
> @@ -902,7 +902,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
> u_domctl)
>          vcpu_unpause(v);
>  
>  #ifdef CONFIG_COMPAT
> -        if ( !is_pv_32on64_domain(d) )
> +        if ( !has_32bit_shinfo(d) )
>              ret = copy_to_guest(op->u.vcpucontext.ctxt, c.nat, 1);
>          else
>              ret = copy_to_guest(guest_handle_cast(op->u.vcpucontext.ctxt,

Where is it written down what format 32-bit PVH guests' vCPU
contexts get passed in? It would seem to me that it would be
rather more natural for them to use the 64-bit layout. Or else
how do you intend to suppress them being able to enter 64-bit
mode?

Jan


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