From mboxrd@z Thu Jan  1 00:00:00 1970
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH v3] x86/HVM: Merge HVM and PVH hypercall
 tables
Date: Fri, 18 Dec 2015 11:57:06 -0500
Message-ID: <56743AE2.3070206@oracle.com>
References: <1450393254-4285-1-git-send-email-boris.ostrovsky@oracle.com>
	<56743443.3070907@citrix.com>
	<5674446D02000078000C1630@prv-mh.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <5674446D02000078000C1630@prv-mh.provo.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>, keir@xen.org
Cc: xen-devel@lists.xen.org, roger.pau@citrix.com
List-Id: xen-devel@lists.xenproject.org

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