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

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Jan,

On 06/17/2014 09:34 AM, Jan Beulich wrote:
>>>> On 16.06.14 at 18:18, <julien.grall@xxxxxxxxxx> 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 <ian.jackson@xxxxxxxxxxxxx>
Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Ian Campbell <ian.campbell@xxxxxxxxxx>
xen-devel@xxxxxxxxxxxxx

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

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