Re: [Xen-devel] [RFC 14/19] xen/passthrough: dt: Add new domctl XEN_DOMCTL_assign_dt_device

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 06/17/2014 02:30 PM, Jan Beulich wrote:
>>>> On 17.06.14 at 15:23, <julien.grall@xxxxxxxxxx> wrote:
>> On 06/17/2014 09:34 AM, Jan Beulich wrote:
>>>>>> On 16.06.14 at 18:18, <julien.grall@xxxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel