[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 20/24] xen/passthrough: Extend XEN_DOMCTL_assign_device to support DT device



Hi Daniel,

On 23/02/15 16:25, Daniel De Graaf wrote:
> On 02/20/2015 12:17 PM, Ian Campbell wrote:
>> On Tue, 2015-01-13 at 14:25 +0000, Julien Grall wrote:
>>> TODO: Update the commit message
>>>
>>> A device node is described by a path. It will be used to retrieved the
>>> node in the device tree and assign the related device to the domain.
>>>
>>> Only device protected by an IOMMU can be assigned to a guest.
>>>
>>> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
>>> Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
>>> Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
>>> Cc: Jan Beulich <jbeulich@xxxxxxxx>
>>>
>>> ---
>>>      Changes in v2:
>>>          - Use a different number for XEN_DOMCTL_assign_dt_device
>>> ---
>>>   tools/libxc/include/xenctrl.h         | 10 ++++
>>>   tools/libxc/xc_domain.c               | 95
>>> ++++++++++++++++++++++++++++++++--
>>
>> These bits all look fine.
>>
>>> +int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
>>> +                       XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>>> +{
>>> +    int ret;
>>> +    struct dt_device_node *dev;
>>> +
>>> +    /* TODO: How to deal with XSM? */
>>
>> Adding Daniel.
>>
>> It seems the PCI ones are protected by
>>          xsm_test_assign_device(XSM_HOOK,
>> domctl->u.assign_device.machine_sbdf);
>>
>> So it seem that either this needs to become "test_assign_pci_device" and
>> a similar "test_assign_dt_device" needs to be added and plumbed through
>> or it needs to grow a type parameter and take the union for the
>> identifier.
> 
> Either would work, but a distinct hook seems simpler to me, especially as
> the call sites are distinct and the hook would process them differently.

Sounds good.

>> The code to apply an XSM context to a DT node would need consideration
>> too I suppose?
> 
> This may require a bit more thought.  At first glance, the dt_phandle
> field seems to be an identifier that could be used by FLASK to identify a
> device using an ocontext lookup.  Labeling would then be done in the same
> way as PCI devices and x86 legacy I/O ports.

We don't always have a dt_phandle in hand. They are mostly used for
referencing a node within another (such as IOMMU, interrupt
controller...). Also, the value is controlled by the compiler.

AFAICT, the only unique value we have in hand is the path of the device.

BTW, do you have any pointer on how to write a policy for device/IRQ
passthrough?

Regards,

-- 
Julien Grall

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.