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:48:42 +0100 Message-ID: <53A0473A.7090902@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> <53A04134.8040909@linaro.org> <53A05F1B020000780001B13C@mail.emea.novell.com> 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 1Wwtkk-0000NO-MX for xen-devel@lists.xenproject.org; Tue, 17 Jun 2014 13:48:46 +0000 Received: by mail-wi0-f175.google.com with SMTP id r20so5904818wiv.8 for ; Tue, 17 Jun 2014 06:48:44 -0700 (PDT) In-Reply-To: <53A05F1B020000780001B13C@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 On 06/17/2014 02:30 PM, Jan Beulich wrote: >>>> On 17.06.14 at 15:23, wrote: >> On 06/17/2014 09:34 AM, Jan Beulich wrote: >>>>>> On 16.06.14 at 18:18, wrote: >>>> @@ -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. > > But that may mean more diverging code on the tools side. Unless the > current PCI model is wrong or unusable for DT pass-through, I think > best would be to retain the abstract model as is. I looked at the libxl code for pci and this is only used in libxl__device_pci_add just before calling do_pci_add in case of an HVM. I'm not sure why we function is used but from the DT pass-through POV, we only need to ask the hypervisor to assign this specific device to the guest. The hypercall will return "ok" if it has succeeded or an error if the device is not protected (i.e not behind an IOMMU). I don't see why we should have a test-assign hypercall in this case... Anyway, I'm fine to introduce the hypercall for consistency but I don't plan to use it in the toolstack because it's pointless. Regards, -- Julien Grall