Re: [Xen-devel] [PATCH v3] x86/HVM: Merge HVM and PVH hypercall tables

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 12/18/2015 11:37 AM, Jan Beulich wrote:
> > > > On 18.12.15 at 17:28, <andrew.cooper3@xxxxxxxxxx> wrote:
> > On 17/12/15 23:00, Boris Ostrovsky wrote:
> > > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> > > index a7767f8..871aca0 100644
> > > --- a/xen/arch/x86/mm.c
> > > +++ b/xen/arch/x86/mm.c
> > > @@ -3019,6 +3019,25 @@ long do_mmuext_op(
> > >               break;
> > >           }
> > >   
> > > +        if ( has_hvm_container_domain(d) )
> > > +        {
> > > +            switch ( op.cmd )
> > > +            {
> > > +            case MMUEXT_PIN_L1_TABLE:
> > > +            case MMUEXT_PIN_L2_TABLE:
> > > +            case MMUEXT_PIN_L3_TABLE:
> > > +            case MMUEXT_PIN_L4_TABLE:
> > > +            case MMUEXT_UNPIN_TABLE:
> > > +                if ( is_control_domain(d) )
> > > +                    break;
> > This needs to be an XSM check, rather than a dom0 check.  Consider the
> > usecase of a PVH/DMLite domain builder stubdomain.
> But wouldn't that be the control domain then? Afaict by making this
> an XSM check we'd also permit the hardware domain access to these,
> for no reason. In fact we should probably further restrict this to
> d != pg_owner.
We already do this at the top of do_mmuext_op():
    rc = xsm_mmuext_op(XSM_TARGET, d, pg_owner);

In fact, there is xsm_memory_pin_page() test under pin_page label so I 
wonder whether I need any test, including is_control_domain()? (Maybe 
for the UNPIN).
-boris


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