All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Oleksandr <olekstysh@gmail.com>,
	xen-devel@lists.xenproject.org,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Subject: Re: [Xen-devel] [PATCH V2 2/6] iommu/arm: Add ability to handle deferred probing request
Date: Thu, 15 Aug 2019 13:54:47 +0100	[thread overview]
Message-ID: <44ba5fba-48c3-f352-510c-fc0d8ada181a@arm.com> (raw)
In-Reply-To: <becf5395-56cd-ccc6-4931-0e3854532ac8@arm.com>

Hi,

On 15/08/2019 10:29, Julien Grall wrote:
> On 14/08/2019 20:25, Stefano Stabellini wrote:
>> On Wed, 14 Aug 2019, Julien Grall wrote:
>> I agree that we should enable all IOMMUs or none. I don't think we want
>> to deal with partially initialized IOMMUs systems.
>>
>> Failure to enable all IOMMUs should lead to returning an error from the
>> relevant function (arch_iommu_populate_page_table?) which should
> 
> The patch is:
> 
> |> start_xen()
> |>   iommu_setup()
> |>     iommu_hardware_setup()
> 
>> translate into Xen failing to boot and crashing. Which I think it is
>> what you are suggesting, right?
> 
> That's correct. At the moment the return value of iommu_setup() is ignored. What 
> I would like to suggest is something along the following lines:
> 
> rc = iommu_setup();
> if ( iommu_enable && rc != -ENODEV )
>    panic("Unable to setup IOMMUs");
> 
>>
>> (I wouldn't call panic() inside the IOMMU specific initializer, because
>> there might be iommu= command line options for Xen that specify a
>> different desired outcome. I would deal with this case the same way we
>> would deal with an error during initialization of a single IOMMU.)
> 
> I am not sure to understand this. If you have an half initialized IOMMU (note 
> the "single" here!), then continuing is likely to make things much worst.
> 
> I don't advocate to put the panic() inside the IOMMU specific initializer (see 
> above). But clearly, we should return an error no matter the content of 'iommu' 
> command line if the user requested to enable the IOMMUs (if any). It wouldn't be 
> right if the user can say "ignore IOMMU error" as most likely you will have 
> unexpected error afterwards.

I noticed there was already a panic() in iommu_setup() just in case the user
force the use of IOMMU but they were not initialized. I was half-tempted to set
iommu_force to true for Arm, but I think this is a different issue.

So here my take (not tested nor compiled).

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 2c5d1372c0..8f94f618b0 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -755,6 +755,7 @@ void __init start_xen(unsigned long boot_phys_offset,
         .max_grant_frames = gnttab_dom0_frames(),
         .max_maptrack_frames = opt_max_maptrack_frames,
     };
+    int rc;
 
     dcache_line_bytes = read_dcache_line_bytes();
 
@@ -890,7 +891,9 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     setup_virt_paging();
 
-    iommu_setup();
+    rc = iommu_setup();
+    if ( !iommu_enabled && rc != -ENODEV )
+        panic("Couldn't configure correctly all the IOMMUs.");
 
     do_initcalls();
 
diff --git a/xen/drivers/passthrough/arm/iommu.c b/xen/drivers/passthrough/arm/iommu.c
index 2135233736..f219de9ac3 100644
--- a/xen/drivers/passthrough/arm/iommu.c
+++ b/xen/drivers/passthrough/arm/iommu.c
@@ -51,6 +51,14 @@ int __init iommu_hardware_setup(void)
         rc = device_init(np, DEVICE_IOMMU, NULL);
         if ( !rc )
             num_iommus++;
+        /*
+         * Ignore the following error codes:
+         *   - EBADF: Indicate the current not is not an IOMMU
+         *   - ENODEV: The IOMMU is not present or cannot be used by
+         *     Xen.
+         */
+        else if ( rc != -EBADF && rc != -ENODEV )
+            return rc;
     }
 
     return ( num_iommus > 0 ) ? 0 : -ENODEV;




> 
> Cheers,
> 

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-08-15 12:55 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-02 16:39 [Xen-devel] [PATCH V2 0/6] iommu/arm: Add Renesas IPMMU-VMSA support + Linux's iommu_fwspec Oleksandr Tyshchenko
2019-08-02 16:39 ` [Xen-devel] [PATCH V2 1/6] iommu/arm: Add iommu_helpers.c file to keep common for IOMMUs stuff Oleksandr Tyshchenko
2019-08-09 17:35   ` Julien Grall
2019-08-09 18:10     ` Oleksandr
2019-08-02 16:39 ` [Xen-devel] [PATCH V2 2/6] iommu/arm: Add ability to handle deferred probing request Oleksandr Tyshchenko
2019-08-12 11:11   ` Julien Grall
2019-08-12 12:01     ` Oleksandr
2019-08-12 19:46       ` Julien Grall
2019-08-13 12:35         ` Oleksandr
2019-08-14 17:34           ` Julien Grall
2019-08-14 19:25             ` Stefano Stabellini
2019-08-15  9:29               ` Julien Grall
2019-08-15 12:54                 ` Julien Grall [this message]
2019-08-15 13:14                   ` Oleksandr
2019-08-15 16:39                     ` Oleksandr
2019-08-02 16:39 ` [Xen-devel] [PATCH V2 3/6] [RFC] xen/common: Introduce _xrealloc function Oleksandr Tyshchenko
2019-08-05 10:02   ` Jan Beulich
2019-08-06 18:50     ` Oleksandr
2019-08-07  6:22       ` Jan Beulich
2019-08-07 17:31         ` Oleksandr
2019-08-06 19:51     ` Volodymyr Babchuk
2019-08-07  6:26       ` Jan Beulich
2019-08-07 18:36         ` Oleksandr
2019-08-08  6:08           ` Jan Beulich
2019-08-08  7:05           ` Jan Beulich
2019-08-08 11:05             ` Oleksandr
2019-08-02 16:39 ` [Xen-devel] [PATCH V2 4/6] iommu/arm: Add lightweight iommu_fwspec support Oleksandr Tyshchenko
2019-08-13 12:39   ` Julien Grall
2019-08-13 15:17     ` Oleksandr
2019-08-13 15:28       ` Julien Grall
2019-08-13 16:18         ` Oleksandr
2019-08-13 13:40   ` Julien Grall
2019-08-13 16:28     ` Oleksandr
2019-08-02 16:39 ` [Xen-devel] [PATCH V2 5/6] iommu/arm: Introduce iommu_add_dt_device API Oleksandr Tyshchenko
2019-08-13 13:49   ` Julien Grall
2019-08-13 16:05     ` Oleksandr
2019-08-13 17:13       ` Julien Grall
2019-08-02 16:39 ` [Xen-devel] [PATCH V2 6/6] iommu/arm: Add Renesas IPMMU-VMSA support Oleksandr Tyshchenko
2019-08-07  2:41   ` Yoshihiro Shimoda
2019-08-07 16:01     ` Oleksandr
2019-08-07 19:15       ` Julien Grall
2019-08-07 20:28         ` Oleksandr Tyshchenko
2019-08-08  9:05           ` Julien Grall
2019-08-08 10:14             ` Oleksandr
2019-08-08 12:44               ` Julien Grall
2019-08-08 15:04                 ` Oleksandr
2019-08-08 17:16                   ` Julien Grall
2019-08-08 19:29                     ` Oleksandr
2019-08-08 20:32                       ` Julien Grall
2019-08-08 23:32                         ` Oleksandr Tyshchenko
2019-08-09  9:56                           ` Julien Grall
2019-08-09 18:38                             ` Oleksandr
2019-08-08 12:28         ` Oleksandr
2019-08-08 14:23         ` Lars Kurth
2019-08-08  4:05       ` Yoshihiro Shimoda
2019-08-14 17:38   ` Julien Grall
2019-08-14 18:45     ` Oleksandr
2019-08-05  7:58 ` [Xen-devel] [PATCH V2 0/6] iommu/arm: Add Renesas IPMMU-VMSA support + Linux's iommu_fwspec Oleksandr
2019-08-05  8:29   ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44ba5fba-48c3-f352-510c-fc0d8ada181a@arm.com \
    --to=julien.grall@arm.com \
    --cc=oleksandr_tyshchenko@epam.com \
    --cc=olekstysh@gmail.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.