From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v3 20/24] xen/passthrough: Extend XEN_DOMCTL_assign_device to support DT device Date: Wed, 11 Mar 2015 12:37:14 +0000 Message-ID: <1426077434.21353.237.camel@citrix.com> References: <1421159133-31526-1-git-send-email-julien.grall@linaro.org> <1421159133-31526-21-git-send-email-julien.grall@linaro.org> <1424452643.30924.368.camel@citrix.com> <54FF1CF6.5030702@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YVft1-0001lB-GB for xen-devel@lists.xenproject.org; Wed, 11 Mar 2015 12:37:19 +0000 In-Reply-To: <54FF1CF6.5030702@linaro.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall Cc: Wei Liu , tim@xen.org, Ian Jackson , stefano.stabellini@citrix.com, Jan Beulich , xen-devel@lists.xenproject.org, Daniel De Graaf List-Id: xen-devel@lists.xenproject.org On Tue, 2015-03-10 at 16:33 +0000, Julien Grall wrote: > Hi Ian, > > On 20/02/15 17:17, Ian Campbell wrote: > >> + /* TODO: Do we need to check is_dying? Mostly to protect against > >> + * hypercall trying to passthrough a device while we are > >> + * dying. > > > > FWIW the PCI case appears not to care... > > There is one place in XEN_DOMCTL_assign_device... > > Although I don't understand much the usage of is_dying. > > >> + */ > >> + > >> + switch ( domctl->cmd ) > >> + { > >> + case XEN_DOMCTL_assign_device: > >> + ret = -ENOSYS; > >> + if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_DT ) > >> + break; > > > > You added something similar to iommu_do_pci_domctl, would it not be > > preferable for the caller to switch on domctl->u.assign_device.dev and > > call the correct iommu_do_*_domctl? > > I though about it. It would require to stub iommu_do_*_domctl. So I > preferred to chose the current solution. You mean iommu_do_{pci,dt}_domctl? IIRC you already added suitable #defines for when these features are present, so reusing them at the call sites wouldn't be too bad, or else stubs aren't the worst thing either.