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

Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>
  • Date: Wed, 25 Jun 2025 19:56:34 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=qqS6g+CWXgeqBpi8r4n+GYpZYOddUpw/F9eMXxh0q3g=; b=KVDgiidMf2l95GrPhNHLNxr4IjaFXjvEuCLNXaowUAisYfgPo0+N12xgseU8s1kMabc/XcLiWHdap4b7eYJfmwc6GSPegOJDWAH7rS1q+eGyeVEYyGrqFMwRFw+sKPo5x50GtgWNX7Na1nTfPyBMuYXHP+zwKep6tPr5YrcgqThlB9r7xGxVVKQqJMgHm0noSAWXiQxKdtgZwCoemuPrbhLo9VTdmUrbE/nA33dlI6hnLUpYcf+UEl233LPZpu8xUPTXe5JUCKLCOaEe6hnh1xdgc0HH1+v781wglvn7kYpaAxDKiYczIsUm0nyE+vdV2XgWzCvaAt1/53J0argMnw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=b99ohGESLUWaDKisqo/DEmbL6i7TNOgYkZZrikSmy7Bi3B+5xVonyO19k1p2yDdoCUlm3moVnFCdxqJeWpxeh6rgb2mlz5hozSf3J/sSbNd3IDWdZGBgn0xthWrBobBLqP+fWRRnp682k2wZm3m3KxLC/hbKS9JJsBUvXiNUbmltwBwQFGb2FFkDy0tRjgeGTX/k3AOs6+NPL7K2oZJ9C7j/n2QeJ3CItH1zYDb4ZUbAr5JyPJCED9aFJrvS/hWcMwioGPQSr0YtmOd0J6C2Ypzgjp1nU1OXgaMctOB7mi06guIO94zLm6v59kVMDn1gHPK221rUiToIQcGR1So3/w==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Grygorii Strashko <grygorii_strashko@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • Delivery-date: Wed, 25 Jun 2025 19:56:41 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHbyNXPDXt2FT3RV02cltfdm/Dd7rPdzmiAgCG+LgCACKrsAIACoXoAgAWykoCAA/lGgA==
  • Thread-topic: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu

On 23/06/2025 10:15, Jan Beulich wrote:
> On 19.06.2025 18:15, Oleksii Moisieiev wrote:
>> On 18/06/2025 03:04, Stefano Stabellini wrote:
>>> On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
>>>>>> diff --git a/xen/arch/arm/firmware/sci.c b/xen/arch/arm/firmware/sci.c
>>>>>> index e1522e10e2..8efd541c4f 100644
>>>>>> --- a/xen/arch/arm/firmware/sci.c
>>>>>> +++ b/xen/arch/arm/firmware/sci.c
>>>>>> @@ -126,6 +126,43 @@ int sci_assign_dt_device(struct domain *d, struct 
>>>>>> dt_device_node *dev)
>>>>>>         return 0;
>>>>>>     }
>>>>>>     
>>>>>> +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d,
>>>>>> +                  XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>>>>>> +{
>>>>>> +    struct dt_device_node *dev;
>>>>>> +    int ret = 0;
>>>>>> +
>>>>>> +    switch ( domctl->cmd )
>>>>>> +    {
>>>>>> +    case XEN_DOMCTL_assign_device:
>>>>>> +        ret = -EOPNOTSUPP;
>>>>> Are you sure -EOPNOTSUPP is the right error code for the 3 checks below?
>>>> The -EOPNOTSUPP code is used because this is part of a chained call after
>>>> iommu_do_domctl, as stated in xen/common/domctl.c:859. The
>>>> XEN_DOMCTL_assign_device
>>>> call is expected to handle any DT device, regardless of whether the DT
>>>> device is
>>>> protected by an IOMMU or if the IOMMU is disabled.
>>>> The following cases are considered:
>>>>
>>>> 1. IOMMU Protected Device (Success)
>>>>
>>>> If the device is protected by the IOMMU and iommu_do_domctl returns 0,
>>>> we continue
>>>> processing the DT device by calling sci_do_domctl.
>>>>
>>>> 2. IOMMU Disabled (-EOPNOTSUPP from iommu_do_domctl)
>>>>
>>>> If iommu_do_domctl returns -EOPNOTSUPP, indicating that the IOMMU is
>>>> disabled,
>>>> we still proceed to call sci_do_domctl.
>>> OK this makes sense.  I think it is OK to have a special error code to
>>> say "the IOMMU is disabled" but I don't know if it is a good idea to try
>>> to use -EOPNOTSUPP for that. -EOPNOTSUPP could mean a hypervisor
>>> configuration with domctl disabled, for instance.
>>>
>>> It might be wiser to use a different error code. Maybe ENOENT?
>>>
>> I see that in the following commit:
>>
>> 71e617a6b8 (use is_iommu_enabled() where appropriate..., 2019-09-17)
>>
>> -ENOSYS return code was changed to -EOPNOTSUPP in iommu_do_domctl.
>>
>> It's not clear to me why this was done from the commit description.
> This has been discussed many times elsewhere. Many of our ENOSYS uses are
> simply wrong. ENOSYS has very limited applicability: Unavailability of a
> top-level hypercall (originally: syscall).
>
What is your opinion about changing it to -ENOENT to say "the IOMMU is 
disabled" as Stefano suggested in [0]?

[0]: https://lists.xen.org/archives/html/xen-devel/2025-06/msg01233.html

 


Rackspace

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