Re: [Xen-devel] [PATCH v3 3/4] x86/pvh: Handle hypercalls for 32b PVH guests

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 07/23/2015 10:21 AM, Jan Beulich wrote:
> > > > On 11.07.15 at 00:20, <boris.ostrovsky@xxxxxxxxxx> wrote:
> > Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
> > ---
> > Changes in v3:
> > * Defined compat_mmuext_op(). (XEN_GUEST_HANDLE_PARAM(mmuext_op_compat_t)
> >    is not defined in header files so I used 'void' type.
> How is it not? It's in compat/xen.h (which is a generated header).
compat/xen.h has DEFINE_COMPAT_HANDLE(mmuext_op_compat_t) (which is 
__compat_handle_mmuext_op_compat_t).
We need XEN_GUEST_HANDLE(mmuext_op_compat_t), which is 
__guest_handle_mmuext_op_compat_t. And I wasn't sure it's worth 
explicitly adding it to a header file (like I think what we do for 
vcpu_runstate_info_compat_t in sched.h);

> > @@ -4951,6 +4950,29 @@ static hvm_hypercall_t *const 
> > pvh_hypercall64_table[NR_hypercalls] = {
> >       [ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
> >   };
> >   
> > +extern int compat_mmuext_op(XEN_GUEST_HANDLE_PARAM(void) cmp_uops,
> > +                            unsigned int count,
> > +                            XEN_GUEST_HANDLE_PARAM(uint) pdone,
> > +                            unsigned int foreigndom);
> > +static hvm_hypercall_t *const pvh_hypercall32_table[NR_hypercalls] = {
> > +    HYPERCALL(platform_op),
> > +    COMPAT_CALL(memory_op),
> > +    HYPERCALL(xen_version),
> > +    HYPERCALL(console_io),
> > +    [ __HYPERVISOR_grant_table_op ]  =
> > +        (hvm_hypercall_t *)hvm_grant_table_op_compat32,
> > +    COMPAT_CALL(vcpu_op),
> > +    COMPAT_CALL(mmuext_op),
> > +    HYPERCALL(xsm_op),
> > +    COMPAT_CALL(sched_op),
> > +    HYPERCALL(event_channel_op),
> > +    [ __HYPERVISOR_physdev_op ] = (hvm_hypercall_t *)hvm_physdev_op_compat32,
> > +    HYPERCALL(hvm_op),
> > +    HYPERCALL(sysctl),
> > +    HYPERCALL(domctl),
> > +    [ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
> Looks like you didn't fully sync with staging - did you forget that it
> was you who added xenpmu_op to the 64-bit counterpart?
I think I posted this before VPMU got committed. But yes...

> Without that ...
>
> > @@ -4981,7 +5003,7 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
> >           return viridian_hypercall(regs);
> >   
> >       if ( (eax >= NR_hypercalls) ||
> > -         (is_pvh_domain(currd) ? !pvh_hypercall64_table[eax]
> > +         (is_pvh_domain(currd) ? !pvh_hypercall32_table[eax]
> >                                  : !hvm_hypercall32_table[eax]) )
> ... this will break (as we're assuming 32- and 64-bit tables to be fully
> in sync here; there's still the pending work item of constructing these
> tables so that this has a better chance of not getting broken).
So you prefer to have full check --- explicitly for both 32- and 64-bit, 
right?
-boris


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