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

Re: [PATCH v4] xen/iommu: cleanup iommu related domctl handling


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 22 Apr 2022 09:09:24 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jMX/ZkCefo+xl6c48nIAY5xxfgtI5L33BHnHz7NMMTk=; b=JH6Y3jon3HhaJhO+lQ4KfClorI7M/vndzXpSVZp5CXGRPC9AENZKH9k+nJ+euD7ZkfK0DlbrJXb8E/tBQOfIwtOLX18LhfzcX/AqDg5ulYWEdx7LnH8MHcoJ3gS+YcO0LsmRl35PldiD/YNzX89QfLFcYZ6Ox8M5KZ1bTbp3ChGw7pkwse5Yvj/nYJR6MGZbI7y1FkzESTJnkN7JO68d3f8ecjSzMHVBMl7EHPH7UbpYTKidLzjYwhfFoag4NobYl3oiZD5livUPnKdb5gAqDAdT28dVmEa2+QMcMB++Q/I8vM2V0dB0gLE2dlolthC8+otO+ar2hWIrrvbVR1PF8A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YExrMOCCUCoYEZsXZbvrMckY1m/BdyzoDlyA1y1HsG3E7lOI2WjebvCussIcSxJIYiHWSFJ6EeoK3Qurpg6GRzHZsqX4pIlRHVJSMx73mTVeZVvzEctOxxp+BPrplxdKFtS5UV3vZGFFfB/E1wIcxAp9Yr0E3o5HPGuULdhuNOFkf5267waltj26kEshnAM4+ILOIGLb402bbYvAi7SyYuSdebmNlDZ3jEHA+mkJIh1/O0wMRFBZfI/XrMF2IHTRWGIhKNMfiZJu4R6I6O6oxk8L99RQ/rYeqdfZCia6dJ2I7QuiyZDWZgvqycGUoQypSe7yNqNiz+fw2R9tyeDptw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>
  • Delivery-date: Fri, 22 Apr 2022 07:09:32 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 21.04.2022 19:47, Andrew Cooper wrote:
> On 20/04/2022 07:27, Jan Beulich wrote:
>> On 20.04.2022 08:22, Juergen Gross wrote:
>>> On 20.04.22 08:11, Jan Beulich wrote:
>>>> On 20.04.2022 07:57, Juergen Gross wrote:
>>>>> --- a/xen/include/xen/iommu.h
>>>>> +++ b/xen/include/xen/iommu.h
>>>>> @@ -341,8 +341,17 @@ struct domain_iommu {
>>>>>   /* Does the IOMMU pagetable need to be kept synchronized with the P2M */
>>>>>   #ifdef CONFIG_HAS_PASSTHROUGH
>>>>>   #define need_iommu_pt_sync(d)     (dom_iommu(d)->need_sync)
>>>>> +
>>>>> +int iommu_do_domctl(struct xen_domctl *domctl, struct domain *d,
>>>>> +                    XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
>>>>>   #else
>>>>>   #define need_iommu_pt_sync(d)     ({ (void)(d); false; })
>>>>> +
>>>>> +static inline int iommu_do_domctl(struct xen_domctl *domctl, struct 
>>>>> domain *d,
>>>>> +                                  XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
>>>>> u_domctl)
>>>>> +{
>>>>> +    return -ENOSYS;
>>>>> +}
>>>> As said in reply to Andrew as well as in a number or earlier occasions,
>>>> I firmly think that this wants to be -EOPNOTSUPP, not -ENOSYS. Views
>>> In libxl there is an explicit check for ENOSYS being returned for
>>> assigning/deassigning a device, same in the xc python bindings.
>> Urgh.
> 
> Honestly, I wasn't particularly happy with your push to swap ENOSYS out
> for EOPNOTSUPP.  This shows plainly why it's a bad move.
> 
> An end user doesn't give two hoots about the distinction between
> hypercall not supported and subops not supported; they care about
> whether Xen can perform the requested action or not.  ENOSYS is the more
> common way of signalling this, and having only one errno value to check
> is better for everyone involved.

End users are of little interest here. Code looking for ENOSYS is what
is of interest, when the meaning of ENOSYS is quite well defined as
"system call not implemented" (which we merely extend to "hypercall").
Anything smaller scope than a major hypercall cannot possibly be
"hypercall not implemented". Code caring about knowing one vs the
other should not be misguided, and code looking for one when the other
is meant is simply flawed.

Jan




 


Rackspace

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