From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v3] x86/HVM: Merge HVM and PVH hypercall tables Date: Fri, 18 Dec 2015 12:33:24 -0500 Message-ID: <56744364.9000004@oracle.com> References: <1450393254-4285-1-git-send-email-boris.ostrovsky@oracle.com> <56743443.3070907@citrix.com> <5674446D02000078000C1630@prv-mh.provo.novell.com> <56743B8D.3070604@citrix.com> <56744C2502000078000C16E0@prv-mh.provo.novell.com> <56743F78.30609@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56743F78.30609@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , Jan Beulich Cc: Daniel De Graaf , xen-devel@lists.xen.org, keir@xen.org, roger.pau@citrix.com List-Id: xen-devel@lists.xenproject.org On 12/18/2015 12:16 PM, Andrew Cooper wrote: > On 18/12/15 17:10, Jan Beulich wrote: >>>>> On 18.12.15 at 17:59, wrote: >>> On 18/12/15 16:37, Jan Beulich wrote: >>>>>>> On 18.12.15 at 17:28, 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. >>> Any domain needing to construct PV domains needs to be able to make >>> these hypercalls against the target domain. >>> >>> Therefore, the only valid check is whether XSM will permit 'current' to >>> issue the hypercall against 'd', irrespective of whether current is the >>> control domain, the hardware domain, or something else. >>> >>> I think all that is needed is xsm_mmuext_op(XSM_TARGET, d, pg_owner) >> Which, as Boris has just pointed out, is already there. > So it is. That is good. > >> But which also allows the d to issue such operations on itself. Won't get_pg_owner() fail in that case? (domid == curr->domain_id) test? > For safely sake, it is probably having either do_mmuext_op() or the XSM > hook bail early if d is not a PV guest. > > I would hesitate at putting that check inside the hvm conditional at > this point. I am not sure what you meant here. -boris