From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [RFC 14/19] xen/passthrough: dt: Add new domctl XEN_DOMCTL_assign_dt_device Date: Tue, 17 Jun 2014 14:23:00 +0100 Message-ID: <53A04134.8040909@linaro.org> References: <1402935486-29136-1-git-send-email-julien.grall@linaro.org> <1402935486-29136-15-git-send-email-julien.grall@linaro.org> <53A019C5020000780001AE2D@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WwtLw-0007Pd-Ub for xen-devel@lists.xenproject.org; Tue, 17 Jun 2014 13:23:09 +0000 Received: by mail-wg0-f52.google.com with SMTP id b13so6941541wgh.23 for ; Tue, 17 Jun 2014 06:23:03 -0700 (PDT) In-Reply-To: <53A019C5020000780001AE2D@mail.emea.novell.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: Jan Beulich Cc: ian.campbell@citrix.com, Stefano Stabellini , tim@xen.org, Ian Jackson , stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org Hi Jan, On 06/17/2014 09:34 AM, Jan Beulich wrote: >>>> On 16.06.14 at 18:18, wrote: >> --- a/xen/include/public/domctl.h >> +++ b/xen/include/public/domctl.h > > I think you should be Cc-ing all relevant maintainers for common code > (here: interface) changes. Sorry, get_maintainers.pl mislead me on the relevant maintainers (see output below). 42sh> scripts/get_maintainers.pl < this.patch Ian Jackson Stefano Stabellini Ian Campbell xen-devel@lists.xen.org For some reason it doesn't provide neither Keir nor you. > >> @@ -936,6 +936,14 @@ typedef struct xen_domctl_vcpu_msrs xen_domctl_vcpu_msrs_t; >> DEFINE_XEN_GUEST_HANDLE(xen_domctl_vcpu_msrs_t); >> #endif >> >> +/* Device Tree: Assign a non-PCI device to a guest */ >> +struct xen_domctl_assign_dt_device { >> + uint32_t size; /* IN: Length of the path */ >> + XEN_GUEST_HANDLE_64(char) path; /* IN: path to the device tree node */ > > Are paths (encoded as strings) indeed the canonical way of > representing devices? Yes, a device node is uniquely identified by the full path from the root node. This path will look like: /soc/ethernet@fff51000 > How does the tool stack know what is valid > to be passed in here? The path is provided directly by the user. The sanity check is only done in the hypervisor side. >> +}; >> +typedef struct xen_domctl_assign_dt_device xen_domctl_assign_dt_device_t; >> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_dt_device_t); >> + >> struct xen_domctl { >> uint32_t cmd; >> #define XEN_DOMCTL_createdomain 1 >> @@ -1008,6 +1016,7 @@ struct xen_domctl { >> #define XEN_DOMCTL_cacheflush 71 >> #define XEN_DOMCTL_get_vcpu_msrs 72 >> #define XEN_DOMCTL_set_vcpu_msrs 73 >> +#define XEN_DOMCTL_assign_dt_device 74 > > How come you get away with just one operation here, when for PCI > pass-through we have three (assign, test-assign, and deassign)? As said on my cover letter this a very very RFC. I send it to have some comment about the design. For now device are reassign directly in Xen when the domain is destroyed. I plan to implement deassign in the next version. I don't think test-assign is useful for non-PCI passthrough. The assign hypercall will correctly check if we can passthrough this device to the guest. Regards, -- Julien Grall