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

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 12/18/2015 11:37 AM, Jan Beulich wrote:
>>>> On 18.12.15 at 17:28, <andrew.cooper3@citrix.com> 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